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
8263658: Use the blessed modifier order in java.base #2993
Conversation
|
@alblue The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
/cc @shipilev |
@alblue The label
|
Please change the synopsis to "8263658: Use the blessed modifier order in java.base" to get this PR hooked properly to the new bug. Also configure the run the testing, see "Pre-submit test status" in "Checks". |
Webrevs
|
@alblue 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 44 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RogerRiggs, @cl4es) but any other Committer may sponsor as well.
|
/integrate |
@alblue |
@@ -49,7 +49,7 @@ | |||
* If the domain provided by the client does not match the one received | |||
* from server. | |||
*/ | |||
//public final static int DOMAIN_UNMATCH = 3; | |||
//public static final int DOMAIN_UNMATCH = 3; |
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.
Maybe this one ought to be removed instead?
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.
Yeah, I agree.
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.
Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.
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.
There's another constant with value 3 defined, so I think this is just some left-over.
If you prefer separating out the removal to another RFE I'd remove this particular change from this PR.
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.
Filed #3076 for the removal and updated this PR without it
If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them? |
Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules. A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts. |
Mailing list message from Joe Darcy on core-libs-dev: On 3/18/2021 9:53 AM, Alex Blewitt wrote:
Separate bug numbers please. It is also possible to use an umbrella -Joe |
I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me. |
There's some extra churn in splitting it up, sure, but different modules are often maintained by different people so getting changes that span the entire JDK reviewed might actually take you longer. YMMV. I can assist creating RFEs. |
/integrate |
/sponsor |
@cl4es @alblue Since your change was applied there have been 47 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit b49c589. |
Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using
final static
thestatic final
should be preferred.This fixes the issues in the
java.base
package for ease of reviewing.https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
Progress
Issue
Reviewers
Download
To checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/2993/head:pull/2993
$ git checkout pull/2993
To update a local copy of the PR:
$ git checkout pull/2993
$ git pull https://git.openjdk.java.net/jdk pull/2993/head