commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] RandomDataImpl refactoring
Date Sun, 06 Nov 2011 01:38:51 GMT
On Sat, Nov 05, 2011 at 08:47:18AM -0700, Phil Steitz wrote:
> 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.

I agree that this seems like a utility that does not nicely fit into Commons
Math.

> 
> 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.

IIUC this example, it indeed has nothing to do with a "mathematical"
application; the feature thus rather belongs in a toolkit for handling
collections of things (like unique IDs).

In "RandomDataImpl", what differentiates "secure" from "non-secure" RNGs is
that for the latter, one can use one of the many _internal_ implementations
of a RNG, while for the former one can only use external ones.

As I mentioned on the JIRA page, not all the "next..." functions can be
"secure". This is inconsistent with respect to the "SecureRandom" class
inheriting from "Random" (thus allowing to call any "next..." methods,
albeit benefiting from the "security").

Finally, the additional layer imposed by the "security" management would
seem to also point to having this functionality in another class.

I'd also suggest that the "RandomData" interface be merged with its unique
implementation (a.k.a. "RandomDataImpl").

If keeping the "secure" utilities, they would go in a new
"SecureRandomData", which can contain only some of the "next..." as you
suggest that not all of them are really needed or useful (in which case I
wonder why the standard "SecureRandom" inherits from "Random"...).


Gilles

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


Mime
View raw message