The comments in MATH-701 included a couple of suggestions for refactoring RandomDataImpl.
1) Eliminate the lazy initialization of the non-secure and secure generators. Have the constructor initialize the generators instead. I am fine with this for the non-secure generator, but initializing a secure random generator can be quite slow, so that is not a good idea. 2) Split out the secure stuff into a separate class, possibly a subclass. I am ambivalent on this one, as I see RandomDataImpl as a utility class and it is convenient to have the most commonly used data generation utilities bundled together. The "secure" methods only generate hex strings, ints and longs. I have never had the need or heard of the need for "secure" gaussians or the other non-secure deviates. Has anyone else? Any comments either way on this? Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org