I would rather keep the ArrayUtils.shuffle() methods not deprecated, and
mention RNG in the Javadoc for more advanced usages. Adding a 100KB
dependency just to shuffle an array isn't optimal.
Emmanuel Bourg
Le 06/12/2022 à 21:40, Gary Gregory a écrit :
I am ok with both LANG and TEXT depreca
I am ok with both LANG and TEXT deprecating to RNG.
Gary
On Tue, Dec 6, 2022, 13:21 Alex Herbert wrote:
> On Tue, 6 Dec 2022 at 17:22, Gary Gregory wrote:
> >
> > I agree this should be in rng.
> >
> > Does rng duplicate all of the lang APIs such that we can deprecate the
> lang
> > methods?
>
On Tue, 6 Dec 2022 at 17:22, Gary Gregory wrote:
>
> I agree this should be in rng.
>
> Does rng duplicate all of the lang APIs such that we can deprecate the lang
> methods?
In short, yes.
(cd src/main && git grep -c Random)
- ArrayUtils
- RandomStringUtils
- RandomUtils
The proposed ArraySamp
I agree this should be in rng.
Does rng duplicate all of the lang APIs such that we can deprecate the lang
methods?
Gary
On Tue, Dec 6, 2022, 09:36 Alex Herbert wrote:
> Currently the [rng] sampler package can only shuffle primitive int[]
> arrays:
>
> o.a.c.rng.sampling.PermutationSampler:
>
On Tue, 6 Dec 2022 at 14:38, Bruno Kinoshita wrote:
>
> Hi Alex,
>
> I also don't have a use case for this right now. What about creating a JIRA
> issue to wait to see if someone has the need for this feature? Maybe users
> will confirm they need it, or provide other suggestions?
>
> -Bruno
I do
Hi Alex,
I also don't have a use case for this right now. What about creating a JIRA
issue to wait to see if someone has the need for this feature? Maybe users
will confirm they need it, or provide other suggestions?
-Bruno
On Tue, 6 Dec 2022 at 15:36, Alex Herbert wrote:
> Currently the [rng
Currently the [rng] sampler package can only shuffle primitive int[] arrays:
o.a.c.rng.sampling.PermutationSampler:
public static void shuffle(UniformRandomProvider rng, int[] list)
public static void shuffle(UniformRandomProvider rng,
int[] list,
int start,
boolean towardHead)
I would
LANG-1254.
Cheers
Bruno
>
> From: Gilles
>To: dev@commons.apache.org
>Sent: Sunday, 16 October 2016 5:08 AM
>Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>Shuffling arrays (was: [RNG] Scope of "Commons RNG&qu
Hi.
On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
[...]
But overall it would be much better to put all this in a new
component
and deprecate all of CL's "Random"-parameterized methods.
It was noted (not only by me) that CL grew too big (and out of its
original
scope). "RandomUtils" is rel
On 27 September 2016 at 12:22, Gilles wrote:
> Hi.
>
> On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
>>
>> Le 27/09/2016 à 01:14, Gilles a écrit :
>>
> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
This should go in the ArrayUtils class of commons-
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
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 T
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 wrote:
> Le 28/09/2016 à 15:28,
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 t
On Wed, Sep 28, 2016 at 4:55 PM, Gilles 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
--
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
wrote:
> On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
>
>> On Wed, Sep 28, 2016 at 1:40 PM, Gilles
>> wrote:
>>
>> If not, then random utilities
On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
On Wed, Sep 28, 2016 at 1:40 PM, Gilles
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
On Wed, Sep 28, 2016 at 1:40 PM, Gilles 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
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, mentione
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.Ran
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
+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
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
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
p
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 mi
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
> "j
Hi.
On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
Le 27/09/2016 à 01:14, Gilles a écrit :
* Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
This should go in the ArrayUtils class of commons-lang, with a
java.util.Random parameter.
I don't get that.
The idea is to
Le 27/09/2016 à 01:14, Gilles a écrit :
>>> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
>>
>> This should go in the ArrayUtils class of commons-lang, with a
>> java.util.Random parameter.
>
> I don't get that.
> The idea is to parameterize the utilities with a "UniformRandomP
27 matches
Mail list logo
