Re: [math] API changes for RC2

[Phil Steitz <ph...@steitz.com>]

> I have the same reservations about creating a dependency. Paul Houle 
> however, has been very open minded in the past and would donate it 
> "officially" to Apache if necessary. It may be simpler just to acquire 
> the whole RngPack source into the math tree and rename the packages so 
> its embedded in our api. Its only about 6 classes anyways. There are a 
> number of improvements I'd like to make to it anyways to provide some 
> more functional helper methods. Its currently under a comparable BSD 
> style license.
> 

This would be very cool.  I just took a close look and I think these 
classes would make an excellent addition if Paul wants to donate them.  In 
any case, we can fairly easily make adaptors.  Here is how I see this 
working (post 1.0).  I am documenting this so that we can move forward 
with 1.0 with the expectation that the changes to the .random classes are 
small enough that they can go in a 1.1.  Please point out significant 
blunders / false assumptions so we can make changes now if we need to.

1) Extract the interface from java.util.Random -- same names and contracts 
for the public methods.  Call this interface RandomGenerator.  It will 
contain:

setSeed(long seed)
nextBytes(byte[] bytes)
int nextInt()
int nextInt(int n)
long nextLong()
boolean nextBoolean()
double nextDouble()
float nextFloat()
double nextGaussian()

2) Modify RandomDataImpl and ValueServer to expose constructors taking 
RandomGenerator arguments and setGenerator(RandomGenerator) methods and 
replace private java.util.Random members with RandomGenerator instances. 
Leave the "secure" methods and SecureRandom members alone - the "secure" 
PRNG is already pluggable.

3) Subclass java.util.Random to implement RandomGenerator and have the 
argumentless constructors for RandomDataImpl, ValueServer create and use 
instances of this class. Call this new class JDKRandomGenerator.

Given the above setup, to adapt RngPack generators as they are now 
implemented, they could be wrapped or extended individually to implement 
RandomGenerator; the abstract class, RandomSeedable, could be modified to 
implement RandomGenerator; or a new abstract base wrapper could be defined 
for the RandomSeedable generators.

All that we use in [math] currently is nextDouble, nextGaussian, setSeed 
and nextBytes. I think it would be convenient for users to add the other 
methods to the RandomGenerator interface as well and to stick with the 
names used in the j.u.Random class.

The changes above to RandomDataImpl and ValueServer and the additional 
interface should not cause backward compatability problems (other than 
serialization) so could be included in a 1.1.

Phil



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org