New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8265137: java.util.Random suddenly has new public methods nowhere documented #3469
Conversation
/label core-libs |
|
@JimLaskey |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks exactly like my proposed solution!
+1 Thanks!
Just my question: Is |
protected methods don't show up. |
/csr |
@AlanBateman has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me this looks fine. It is all a bit of hack, but this makes sure the public API of java.util.Random does not change in comparison to JDK 16.
The final protected method may be visible by IDEs but it cannot be called und is not overrideable as it is final.
I don't see the point of having those methods virtual, they can be public static in RandomSupport given that there is only one implementation (the one with an if ... instanceof). |
src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java
Outdated
Show resolved
Hide resolved
Due to the changes now: I think the CSR got obsolete? |
I put the CSR back to draft until I was happy with the changeset. |
/help |
@JimLaskey Available commands:
|
/help reviewer |
@JimLaskey Available commands:
|
Looks good +1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good.
AbstractSpliteratorGenerator now is a bit weird because it's a utility class that has static methods, and it's an abstract superclass that has instance methods that mostly just call the static methods. Seems to me that additional cleanup is possible. It might not be worth it right now, since the main point of this PR -- to remove "leakage" of these helper methods into the public API -- has been achieved.
The RandomXXXSpliterator nested classes could also stand some scrutiny. The constructors consume a RandomGenerator, which is stored in an instance variable. Various comments still refer to this as an AbstractSpliteratorGenerator. (See line 961 for example; can't comment directly because it's not part of this commit.)
But it's not clear to me that the RandomXXXSpliterator classes really need a full RandomGenerator. For example, as far as I can see, RandomIntSpliterator only needs nextInt
to generate int values; therefore it could be IntSupplier
. Similar for long and double. (I'm applying the Interface Segregation Principle here.) But again this is probably a cleanup for another day.
*/ | ||
protected AbstractSpliteratorGenerator() { | ||
private AbstractSpliteratorGenerator() { | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is wrong now since there are instances of this class (really, subclasses). The constructor should probably simply be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
the overall setup is mch better than before! This also makes the problem we have seen in policeman-tools/forbidden-apis#177 go away, because Random/ThreadLocalRandom no longer extend a public, but internal/hidden class (forbiddenapis is a classfile analyzer that tries to prevent user's from extending internal JDK APIs in one of its checks). When looking into superclasses of Random, it detected a "bad superclass from an internal package".
So this alone makes me very happy with this.
In addition, it no longer changes APIs of Random/ThreadLocalRandom, only the new interface is added.
+1 to merge
Please mark the CSR https://bugs.openjdk.java.net/browse/JDK-8265221 as reviewed. |
@JimLaskey This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the
|
/integrate |
@JimLaskey Pushed as commit 05e6017. |
Move makeXXXSpilterator from public (@hidden) to protected. No API ch
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3469/head:pull/3469
$ git checkout pull/3469
Update a local copy of the PR:
$ git checkout pull/3469
$ git pull https://git.openjdk.java.net/jdk pull/3469/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3469
View PR using the GUI difftool:
$ git pr show -t 3469
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3469.diff