On Fri, 28 Jan 2022 01:06:47 GMT, liach <[email protected]> wrote:
>> Commited the change on df78e05e3e692e2189c9d318fbd4892a4b96a55f
>
> Will we gradually phase out the `Random` class? If yes, we should put this
> conversion method in `Random` so that we don't break the newer API shall
> `Random` be retired.
I don't think Random will ever be removed, so this probably isn't an issue.
There is the overall question of which factoring is preferable: adding a
default method on RandomGenerator, as is done here, or an alternative of adding
a static utility to Random, something like:
// Random.java
public static Random from(RandomGenerator generator) { ... }
This makes the call site a bit longer and adds a level of nesting:
Collections.shuffle(list,
Random.from(RandomGenerator.of("L64X128MixRandom")));
compared to the default method approach:
Collections.shuffle(list,
RandomGenerator.of("L64X128MixRandom").asRandom());
I believe this allows the wrapper class to be placed in java.util, or even as a
nested class of Random, instead of having to be a new top-level class in
jdk.internal.
Another consideration is whether the adapter should be on the "new" thing or on
the "old" thing. There's a little bit of precedent to put adapters on the "old"
thing so that the "new" thing doesn't get polluted with the old. For example,
consider Enumeration::asIterator. (Even though the adaptation is going the
other way in that case, there are still alternative factorings that place the
adapter on the new instead of the old.)
I don't think any of this is compelling but it's worth a discussion.
Regardless of where the adapter ends up, the "other" class should have a note
and a link that refers to the adapter.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7001
