commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] RandomDataImpl refactoring
Date Sat, 05 Nov 2011 15:47:18 GMT
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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message