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
<brent.wor...@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
<gil...@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-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
