You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2016/09/27 11:57:04 UTC
Re: [lang] Shuffling arrays
Le 27/09/2016 � 13:22, Gilles a �crit :
> I (strongly) suggest
>
> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider rnd)
That's not possible, because we don't want to add external dependencies
to commons-lang.
> Moreover, the default RNG should be a good one, i.e. not
> "java.util.Random".
Using java.util.Random by default is good enough, and it's consistent
with Collections.shuffle():
http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#shuffle-java.util.List-
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gary Gregory <ga...@gmail.com>.
I would expect that we provide implementations of this new interface for
all JRE random classes.
On Wed, Sep 28, 2016 at 7:55 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
>
>> On Wed, Sep 28, 2016 at 1:40 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> If not, then random utilities are not best located in Commons Lang,
>>> because indeed the no-dep requirement forces you to go through
>>> "java.util.Random" which is bad (TM) for several reasons, mentioned
>>> here, there, and everywhere.
>>>
>>
>> I agree that RNG could be removed from CL (Binary compatibility
>> considerations left aside). However, rather than introducing
>> unnecessary dependencies, one would instead use an RNG interface, with
>> an ovious default implementation. In other words, if "Joe Average
>> Random" (aka Gilles) wants to use Commons RNG, he's perfectly capable
>> to do so.
>>
>>
> Do you mean that CL must define its own interface, say
>
> interface CommonsLangRandom {
> int nextInt();
> long nextong();
> double nextDouble();
> // and so on.
> }
>
> and that it's up to the user to create the bridge for delegating
> to the library of his choice?
>
> So, in _user_ code:
>
> CommonsLangRandom asCLRandom(final java.util.Random rand) {
> return new CommonsLangRandom() {
> public nextInt() {
> return rand.nextInt();
> }
> }
> }
>
> and/or
>
> CommonsLangRandom asCLRandom(final UniformRandomProvider rand) {
> return new CommonsLangRandom() {
> public nextInt() {
> return rand.nextInt();
> }
> }
> }
>
>
> That's the way how you design low level libraries.
>>
>
> That's seems a good compromise if CL is indeed the low-level
> libray it purports to be.
>
>
> Gilles
>
>
>> Jochen
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [lang] Shuffling arrays
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Sep 28, 2016 at 4:55 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> Do you mean that CL must define its own interface, say
Yes, of course. Btw: Note, that commons-crypto does the same [1].
Jochen
1: https://commons.apache.org/proper/commons-crypto/apidocs/org/apache/commons/crypto/random/CryptoRandom.html
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
> On Wed, Sep 28, 2016 at 1:40 PM, Gilles
> <gi...@harfang.homelinux.org> wrote:
>
>> If not, then random utilities are not best located in Commons Lang,
>> because indeed the no-dep requirement forces you to go through
>> "java.util.Random" which is bad (TM) for several reasons, mentioned
>> here, there, and everywhere.
>
> I agree that RNG could be removed from CL (Binary compatibility
> considerations left aside). However, rather than introducing
> unnecessary dependencies, one would instead use an RNG interface,
> with
> an ovious default implementation. In other words, if "Joe Average
> Random" (aka Gilles) wants to use Commons RNG, he's perfectly capable
> to do so.
>
Do you mean that CL must define its own interface, say
interface CommonsLangRandom {
int nextInt();
long nextong();
double nextDouble();
// and so on.
}
and that it's up to the user to create the bridge for delegating
to the library of his choice?
So, in _user_ code:
CommonsLangRandom asCLRandom(final java.util.Random rand) {
return new CommonsLangRandom() {
public nextInt() {
return rand.nextInt();
}
}
}
and/or
CommonsLangRandom asCLRandom(final UniformRandomProvider rand) {
return new CommonsLangRandom() {
public nextInt() {
return rand.nextInt();
}
}
}
> That's the way how you design low level libraries.
That's seems a good compromise if CL is indeed the low-level
libray it purports to be.
Gilles
>
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Sep 28, 2016 at 1:40 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> If not, then random utilities are not best located in Commons Lang,
> because indeed the no-dep requirement forces you to go through
> "java.util.Random" which is bad (TM) for several reasons, mentioned
> here, there, and everywhere.
I agree that RNG could be removed from CL (Binary compatibility
considerations left aside). However, rather than introducing
unnecessary dependencies, one would instead use an RNG interface, with
an ovious default implementation. In other words, if "Joe Average
Random" (aka Gilles) wants to use Commons RNG, he's perfectly capable
to do so.
That's the way how you design low level libraries.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 11:34:10 -0500, Matt Sicker wrote:
> I thought he meant that if your code works with either Random or
> SecureRandom, you're doing it wrong. They both have very different
> use
> cases, and the fact that SecureRandom extends Random contributes to
> the
> confusion.
Indeed.
[I should have read the thread up to the top before duplicating your
answer.]
Regards,
Gilles
> On 30 September 2016 at 08:02, Emmanuel Bourg <eb...@apache.org>
> wrote:
>
>> Le 28/09/2016 � 15:28, Gilles a �crit :
>>
>> > Conversely, using "SecureRandom" in place of a deterministic
>> > RNG is only useful in toy applications since the main feature
>> > (of non-secure RNGs) one usually needs is reproducibility.
>>
>> I guess the Tomcat developers will love hearing they are building a
>> toy
>> application :)
>>
>> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/
>> java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>>
>>
>> > [1] Even the Java architects have indirectly acknowledged that,
>> > by having a new random-related class _NOT_ extend "Random"
>> > (allowing them to drop all the cruft brought by it).
>>
>> Are you referring to java.security.SecureRandomSpi not extending
>> java.util.Random? This is merely a mechanism allowing to plug extra
>> implementations, the whole security package is designed around this
>> concept. But users only deal with SecureRandom, which extends
>> Random.
>>
>> Emmanuel Bourg
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Matt Sicker <bo...@gmail.com>.
I thought he meant that if your code works with either Random or
SecureRandom, you're doing it wrong. They both have very different use
cases, and the fact that SecureRandom extends Random contributes to the
confusion.
On 30 September 2016 at 08:02, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 28/09/2016 à 15:28, Gilles a écrit :
>
> > Conversely, using "SecureRandom" in place of a deterministic
> > RNG is only useful in toy applications since the main feature
> > (of non-secure RNGs) one usually needs is reproducibility.
>
> I guess the Tomcat developers will love hearing they are building a toy
> application :)
>
> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/
> java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>
>
> > [1] Even the Java architects have indirectly acknowledged that,
> > by having a new random-related class _NOT_ extend "Random"
> > (allowing them to drop all the cruft brought by it).
>
> Are you referring to java.security.SecureRandomSpi not extending
> java.util.Random? This is merely a mechanism allowing to plug extra
> implementations, the whole security package is designed around this
> concept. But users only deal with SecureRandom, which extends Random.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 15:02:40 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 � 15:28, Gilles a �crit :
>
>> Conversely, using "SecureRandom" in place of a deterministic
>> RNG is only useful in toy applications since the main feature
>> (of non-secure RNGs) one usually needs is reproducibility.
>
> I guess the Tomcat developers will love hearing they are building a
> toy
> application :)
A complete misinterpretation of my sentence.
If an application requires a cryptographically secure generator,
then using (i.e. allowing a user to choose) a deterministic one
might incur a vulnerability.
If an application must generate reproducible results, then
allowing a cryptographically secure generator is a useless
feature.
>
>
> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>
>
>> [1] Even the Java architects have indirectly acknowledged that,
>> by having a new random-related class _NOT_ extend "Random"
>> (allowing them to drop all the cruft brought by it).
>
> Are you referring to java.security.SecureRandomSpi not extending
> java.util.Random?
No, "SplittableRandom".
Gilles
> This is merely a mechanism allowing to plug extra
> implementations, the whole security package is designed around this
> concept. But users only deal with SecureRandom, which extends Random.
>
> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2016 � 15:28, Gilles a �crit :
> Conversely, using "SecureRandom" in place of a deterministic
> RNG is only useful in toy applications since the main feature
> (of non-secure RNGs) one usually needs is reproducibility.
I guess the Tomcat developers will love hearing they are building a toy
application :)
https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
> [1] Even the Java architects have indirectly acknowledged that,
> by having a new random-related class _NOT_ extend "Random"
> (allowing them to drop all the cruft brought by it).
Are you referring to java.security.SecureRandomSpi not extending
java.util.Random? This is merely a mechanism allowing to plug extra
implementations, the whole security package is designed around this
concept. But users only deal with SecureRandom, which extends Random.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 28 Sep 2016 13:47:49 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 � 13:40, Gilles a �crit :
>
>> If not, then random utilities are not best located in Commons Lang,
>> because indeed the no-dep requirement forces you to go through
>> "java.util.Random" which is bad (TM) for several reasons, mentioned
>> here, there, and everywhere.
>
> I agree java.util.Random is suboptimal as an implementation, but it's
> perfectly fine as an interface.
It is not. See the post I've just sent.
> It can be swapped with a
> java.security.SecureRandom if quality matters.
The interchangeability of "Random" and "SecureRandom" is beside
the point.
PRNG for cryptographic use, or not, have different priorities
and requirements.
It is only the most superficial analysis that would consider it
important that "SecureRandom" extends "Random".[1]
An application that would allow either is probably not to be
trusted for anything cryptographic.
Conversely, using "SecureRandom" in place of a deterministic
RNG is only useful in toy applications since the main feature
(of non-secure RNGs) one usually needs is reproducibility.
"SecureRandom" have requirements that are utterly foreign to
deterministic implementations (cf. entropy management).
Also "SecureRandom" can be comparatively slow. Letting users
think that they can use them interchangeably is bad advice.
Gilles
[1] Even the Java architects have indirectly acknowledged that,
by having a new random-related class _NOT_ extend "Random"
(allowing them to drop all the cruft brought by it).
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2016 � 13:40, Gilles a �crit :
> If not, then random utilities are not best located in Commons Lang,
> because indeed the no-dep requirement forces you to go through
> "java.util.Random" which is bad (TM) for several reasons, mentioned
> here, there, and everywhere.
I agree java.util.Random is suboptimal as an implementation, but it's
perfectly fine as an interface. It can be swapped with a
java.security.SecureRandom if quality matters.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 27 Sep 2016 18:41:59 -0700, Gary Gregory wrote:
> +1: [lang] is a low-level library, which should not have any deps.
This is fine as a requirement.
But then why don't you draw all the conclusions from that, including
that its scope must be limited, lest the goal is for CL to contain
all the Java code in the world?
If not, then random utilities are not best located in Commons Lang,
because indeed the no-dep requirement forces you to go through
"java.util.Random" which is bad (TM) for several reasons, mentioned
here, there, and everywhere.
Gilles
> Gary
>
> On Tue, Sep 27, 2016 at 5:55 PM, Brent Worden
> <br...@gmail.com>
> wrote:
>
>> There are no good reasons for a component such as commons-lang to
>> have any
>> runtime dependencies beside Java itself. The commons-lang install
>> base is
>> enormous with very diverse usage patterns. Having it coupled to
>> another
>> libraries, regardless of the maintainer, invites all kinds of
>> classloading
>> problems when those libraries have different release cadences.
>>
>> Using java.util.Random as a bridge between commons-lang and
>> commons-rng is
>> a very good solution. It allows for UniformRandomProvider instances
>> to be
>> used by commons-lang by simply adapting the providers to
>> java.util.Random
>> instances. The gives the users of commons-lang the ability to use
>> the RNG
>> of their choosing while allowing them to update the components
>> independently of one another to avoid compatibility problems. This
>> give
>> the components high cohesion in that they can easily be used
>> together and
>> low coupling in that they are only bound via a shared, never
>> changing API.
>>
>> Brent
>>
>> On Tue, Sep 27, 2016 at 11:36 AM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>> > On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
>> >
>> >> Le 27/09/2016 � 13:22, Gilles a �crit :
>> >>
>> >> I (strongly) suggest
>> >>>
>> >>> ArraysUtils.shuffle(Object[] array,
>> o.a.c.rng.UniformRandomProvider
>> >>> rnd)
>> >>>
>> >>
>> >> That's not possible, because we don't want to add external
>> dependencies
>> >> to commons-lang.
>> >>
>> >
>> > I mistakenly thought that your examples (cf. uncut previous post)
>> meant
>> > that this CM-alike tradition was coming to an end...
>> >
>> > Anyway, assuming there are still good reasons for CL to not have
>> > dependencies[1], it is then all the more interesting that
>> utilities
>> > based on RNGs should have their own component.
>> >
>> > CL would benefit (reduced codebase reduces the maintenance cost)
>> > and users would benefit (from using better generators).
>> >
>> > Moreover, the default RNG should be a good one, i.e. not
>> >>> "java.util.Random".
>> >>>
>> >>
>> >> Using java.util.Random by default is good enough, and it's
>> consistent
>> >> with Collections.shuffle():
>> >>
>> >>
>> >> http://docs.oracle.com/javase/8/docs/api/java/util/Collectio
>> >> ns.html#shuffle-java.util.List-
>> >>
>> >
>> > Well, of course, the JDK utilities use the JDK's RNG.
>> >
>> > That doesn't mean that Apache should do the same, or spread bad
>> > practice:
>> > http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
>> > (see page 2 about "java.util.Random").
>> >
>> > Gilles
>> >
>> > [1] Even if those would be in our total control!
>> >
>> >
>> >
>> >> Emmanuel Bourg
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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
Re: [lang] Shuffling arrays
Posted by Gary Gregory <ga...@gmail.com>.
+1: [lang] is a low-level library, which should not have any deps.
Gary
On Tue, Sep 27, 2016 at 5:55 PM, Brent Worden <br...@gmail.com>
wrote:
> There are no good reasons for a component such as commons-lang to have any
> runtime dependencies beside Java itself. The commons-lang install base is
> enormous with very diverse usage patterns. Having it coupled to another
> libraries, regardless of the maintainer, invites all kinds of classloading
> problems when those libraries have different release cadences.
>
> Using java.util.Random as a bridge between commons-lang and commons-rng is
> a very good solution. It allows for UniformRandomProvider instances to be
> used by commons-lang by simply adapting the providers to java.util.Random
> instances. The gives the users of commons-lang the ability to use the RNG
> of their choosing while allowing them to update the components
> independently of one another to avoid compatibility problems. This give
> the components high cohesion in that they can easily be used together and
> low coupling in that they are only bound via a shared, never changing API.
>
> Brent
>
> On Tue, Sep 27, 2016 at 11:36 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
> > On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
> >
> >> Le 27/09/2016 à 13:22, Gilles a écrit :
> >>
> >> I (strongly) suggest
> >>>
> >>> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider
> >>> rnd)
> >>>
> >>
> >> That's not possible, because we don't want to add external dependencies
> >> to commons-lang.
> >>
> >
> > I mistakenly thought that your examples (cf. uncut previous post) meant
> > that this CM-alike tradition was coming to an end...
> >
> > Anyway, assuming there are still good reasons for CL to not have
> > dependencies[1], it is then all the more interesting that utilities
> > based on RNGs should have their own component.
> >
> > CL would benefit (reduced codebase reduces the maintenance cost)
> > and users would benefit (from using better generators).
> >
> > Moreover, the default RNG should be a good one, i.e. not
> >>> "java.util.Random".
> >>>
> >>
> >> Using java.util.Random by default is good enough, and it's consistent
> >> with Collections.shuffle():
> >>
> >>
> >> http://docs.oracle.com/javase/8/docs/api/java/util/Collectio
> >> ns.html#shuffle-java.util.List-
> >>
> >
> > Well, of course, the JDK utilities use the JDK's RNG.
> >
> > That doesn't mean that Apache should do the same, or spread bad
> > practice:
> > http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
> > (see page 2 about "java.util.Random").
> >
> > Gilles
> >
> > [1] Even if those would be in our total control!
> >
> >
> >
> >> Emmanuel Bourg
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [lang] Shuffling arrays
Posted by Brent Worden <br...@gmail.com>.
There are no good reasons for a component such as commons-lang to have any
runtime dependencies beside Java itself. The commons-lang install base is
enormous with very diverse usage patterns. Having it coupled to another
libraries, regardless of the maintainer, invites all kinds of classloading
problems when those libraries have different release cadences.
Using java.util.Random as a bridge between commons-lang and commons-rng is
a very good solution. It allows for UniformRandomProvider instances to be
used by commons-lang by simply adapting the providers to java.util.Random
instances. The gives the users of commons-lang the ability to use the RNG
of their choosing while allowing them to update the components
independently of one another to avoid compatibility problems. This give
the components high cohesion in that they can easily be used together and
low coupling in that they are only bound via a shared, never changing API.
Brent
On Tue, Sep 27, 2016 at 11:36 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
>
>> Le 27/09/2016 à 13:22, Gilles a écrit :
>>
>> I (strongly) suggest
>>>
>>> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider
>>> rnd)
>>>
>>
>> That's not possible, because we don't want to add external dependencies
>> to commons-lang.
>>
>
> I mistakenly thought that your examples (cf. uncut previous post) meant
> that this CM-alike tradition was coming to an end...
>
> Anyway, assuming there are still good reasons for CL to not have
> dependencies[1], it is then all the more interesting that utilities
> based on RNGs should have their own component.
>
> CL would benefit (reduced codebase reduces the maintenance cost)
> and users would benefit (from using better generators).
>
> Moreover, the default RNG should be a good one, i.e. not
>>> "java.util.Random".
>>>
>>
>> Using java.util.Random by default is good enough, and it's consistent
>> with Collections.shuffle():
>>
>>
>> http://docs.oracle.com/javase/8/docs/api/java/util/Collectio
>> ns.html#shuffle-java.util.List-
>>
>
> Well, of course, the JDK utilities use the JDK's RNG.
>
> That doesn't mean that Apache should do the same, or spread bad
> practice:
> http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
> (see page 2 about "java.util.Random").
>
> Gilles
>
> [1] Even if those would be in our total control!
>
>
>
>> Emmanuel Bourg
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
> Le 27/09/2016 � 13:22, Gilles a �crit :
>
>> I (strongly) suggest
>>
>> ArraysUtils.shuffle(Object[] array,
>> o.a.c.rng.UniformRandomProvider rnd)
>
> That's not possible, because we don't want to add external
> dependencies
> to commons-lang.
I mistakenly thought that your examples (cf. uncut previous post) meant
that this CM-alike tradition was coming to an end...
Anyway, assuming there are still good reasons for CL to not have
dependencies[1], it is then all the more interesting that utilities
based on RNGs should have their own component.
CL would benefit (reduced codebase reduces the maintenance cost)
and users would benefit (from using better generators).
>> Moreover, the default RNG should be a good one, i.e. not
>> "java.util.Random".
>
> Using java.util.Random by default is good enough, and it's consistent
> with Collections.shuffle():
>
>
> http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#shuffle-java.util.List-
Well, of course, the JDK utilities use the JDK's RNG.
That doesn't mean that Apache should do the same, or spread bad
practice:
http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
(see page 2 about "java.util.Random").
Gilles
[1] Even if those would be in our total control!
>
> Emmanuel Bourg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org