Hi.
On Mon, 8 Aug 2016 14:08:41 +0300, Artem Barger wrote:
On Mon, Aug 8, 2016 at 1:16 PM, Julien Aymé <julien.a...@gmail.com>
wrote:
IMHO, it would be simpler to add JDKSecureRandom and
JDKThreadLocalRandom classes, so that you know what you have in a
single glance.
WDYT?
IMO make sense, since it will allow to preserve inheritance
relationships
similar
to those of JDK w/ Random, SecureRandom and ThreadLocalRandom
classes.
Of course it's interesting to hear Gilles opinion since he is an
author of
the changes.
Before comparing implementation options, we should consider that
the alternative RNG implementations, as provided by this component,
offer either better performance, or better quality (longer period
and/or more uniformity); most are better than "Random" on all counts.
Why would someone want to use "JDKRandom" then?
[And if they really do want to use the underlying algorithm of
"Random", why not use it directly?]
Class "JDKRandom" is primarily present to serve as a baseline for
benchmarking the other implementations. Other uses are discouraged
because going through this library is getting the "worst of both
worlds", e.g. this library's implementations are not thread-safe
(because it contradicts the purported need for ultimate performance
of such algorithms). Cf. documentation and the discussions on the
"dev" ML).
"SecureRandom" is not part of the intended design goal which is that
Commons Rng is a repository of actual RNG implementations, for all to
see, rather than a framework for "outside" implementations.
Focus is on quality of the generation of uniformly distributed
sequences of numbers.
Whether those sequences can be used in cryptographic applications is
out of scope (although some implementations could be construed as
cryptographically strong, like "ISAACRandom"[1]).
On this point, see also Commons Math "o.a.c.m.random.RandomUtils"
class.
Actually, I was pondering about whether those utilities should also
be moved from Commons Math to Commons Rng.
In the affirmative, I believe that they should be provided in a
different Maven modules emphasizing the orthogonal purposes (e.g.
we'd have commons-rng-core and commons-rng-tools).
Best regards,
Gilles
[1] Without warranty. ;-)
Best regards,
Artem Barger.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
