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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
