On 11/5/11 7:04 AM, Luc Maisonobe wrote: > Le 05/11/2011 08:29, Phil Steitz a écrit : >> 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. > I agree. > >> 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? > The only needs for secure random generators I know of is for creating > crypto keys. I feal this is out of scope of our library. For sure, > crypto is a mathematical thing, but we don't provide anything except > these random generation, which in fact does not do anything fancy but > only requires an underlying secure generator. > > So I would be happy to completely remove this stuff.
What I have used these things for is generating session IDs and integer object IDs that I did not want to be easily predictable. I would prefer to keep the methods that are there. Phil > > Luc > >> Phil >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
