RFR: 8279598: Provide adapter from RandomGenerator to Random [v2]

[Stuart Marks]

On Fri, 28 Jan 2022 01:06:47 GMT, liach <duke at openjdk.java.net> 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