On 3 Oct 2022, at 14:32, Stuart Marks wrote:
> …
> The Arrays class does need some attention and probably should be considered
> separately. It's lacking some other things too, like reverse(). One issue
> with modifying the Arrays class is providing overloads for some or all of the
> primitives
method to perform a shuffle
without having to use asList.
Jason
From: Tagir Valeev
Sent: Saturday, October 1, 2022 2:24 AM
To: Jason Mehrens
Cc: Paul Sandoz; core-libs-dev@openjdk.org
Subject: Re: Collections.shuffle to accept RandomGenerator
Thanks, Paul, Jason. I've filed an issu
ethod to perform a shuffle
without having to use asList.
Jason
From: Tagir Valeev
Sent: Saturday, October 1, 2022 2:24 AM
To: Jason Mehrens
Cc: Paul Sandoz; core-libs-dev@openjdk.org
Subject: Re: Collections.shuffle to accept RandomGenerator
Thanks,
> From: core-libs-dev on behalf of Paul Sandoz
>
> Sent: Wednesday, September 28, 2022 10:36 AM
> To: Tagir Valeev
> Cc: core-libs-dev@openjdk.org
> Subject: Re: Collections.shuffle to accept RandomGenerator
>
> That looks rea
of Paul Sandoz
Sent: Wednesday, September 28, 2022 10:36 AM
To: Tagir Valeev
Cc: core-libs-dev@openjdk.org
Subject: Re: Collections.shuffle to accept RandomGenerator
That looks reasonable.
Thinking a little more broadly.
We could also change Collections.shuffle(List) to use ThreadLocalRandom
That looks reasonable.
Thinking a little more broadly.
We could also change Collections.shuffle(List) to use ThreadLocalRandom so it
does not have to cache the Random instance, plus it has better concurrent and
PRNG properties. The spec does not describe the precise details of randomness.
It’
Hello!
Currently, Collections.shuffle(List, Random) accepts an outdated
Random class instead of RandomGenerator interface. It looks like,
RandomGenerator would suffice. The code change looks trivial (aside
from documentation and testing), as shuffle() implementation does not
need anything except n
