Skip to content
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

8267521: Post JEP 411 refactoring: maximum covering > 50K #4138

Closed
wants to merge 1 commit into from

Conversation

@wangweij
Copy link
Contributor

@wangweij wangweij commented May 21, 2021

The code change refactors classes that have a SuppressWarnings("removal") annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

The code change shows some common solutions to avoid such too wide annotations:

  1. Extract calls into a method and add annotation on that method
  2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called tmp if later reassigned or dummy if it will be discarded.
  3. Put declaration and assignment into a single statement if possible.
  4. Rewrite code to achieve #3 above.

I'll add a copyright year update commit before integration.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138
$ git checkout pull/4138

Update a local copy of the PR:
$ git checkout pull/4138
$ git pull https://git.openjdk.java.net/jdk pull/4138/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4138

View PR using the GUI difftool:
$ git pr show -t 4138

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4138.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 21, 2021

👋 Welcome back weijun! A progress list of the required criteria for merging this PR into pr/4073 will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label May 21, 2021
@openjdk
Copy link

@openjdk openjdk bot commented May 21, 2021

@wangweij The following labels will be automatically applied to this pull request:

  • 2d
  • awt
  • core-libs
  • i18n
  • jmx
  • net
  • security
  • serviceability
  • swing

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.

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 21, 2021

Webrevs

@SuppressWarnings("removal")
final String enc = AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
vals[0] = Integer.getInteger("sun.net.client.defaultReadTimeout", 300_000).intValue();
vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
encs[0] = System.getProperty("file.encoding", "ISO8859_1");
return null;
return System.getProperty("file.encoding", "ISO8859_1");
}
Copy link
Member

@dfuch dfuch May 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

Copy link
Contributor Author

@wangweij wangweij May 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might say we thus avoid wasting the return value, as much as possible.

@@ -551,6 +547,7 @@ private void issueCommandCheck(String cmd) throws sun.net.ftp.FtpProtocolExcepti
* @return the connected <code>Socket</code>
* @throws IOException if the connection was unsuccessful.
*/
@SuppressWarnings("removal")
Copy link
Member

@dfuch dfuch May 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the scope of the annotation be further reduced by applying it to the two places where doPrivileged is called in this method?

Copy link
Contributor Author

@wangweij wangweij May 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to s. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment.

@@ -921,6 +918,7 @@ private void tryConnect(InetSocketAddress dest, int timeout) throws IOException
in = new BufferedInputStream(server.getInputStream());
}

@SuppressWarnings("removal")
Copy link
Member

@dfuch dfuch May 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda...

            PrivilegedAction<Socket> pa = () -> new Socket(proxy);
            @SuppressWarnings("removal")
            var ps = AccessController.doPrivileged(pa);
            s = ps;

dfuch
dfuch approved these changes May 24, 2021
Copy link
Member

@dfuch dfuch left a comment

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

@wangweij
Copy link
Contributor Author

@wangweij wangweij commented May 24, 2021

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of FtpClient.java I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-(

@@ -627,13 +627,15 @@
initIDs();
}

@SuppressWarnings("removal")
Copy link
Contributor

@prrace prrace May 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
that was needed because of the usage in this static block and you could not apply the annotation here.
Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
Can you explain ?

Copy link
Contributor Author

@wangweij wangweij May 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a tiny refactoring here: a new variable s2 is introduced so the 2nd doPrivileged call on line 636 is now also in a declaration statement (for s2) and therefore annotatable. Without this I cannot add the annotation on line 635.

Copy link
Contributor

@prrace prrace May 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. But I will quote you
"This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"

So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.

Why has the explanation changed ?

Copy link
Contributor Author

@wangweij wangweij May 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable.

prrace
prrace approved these changes May 30, 2021
@openjdk-notifier openjdk-notifier bot changed the base branch from pr/4073 to master Jun 2, 2021
@openjdk-notifier
Copy link

@openjdk-notifier openjdk-notifier bot commented Jun 2, 2021

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout 8266459
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk
Copy link

@openjdk openjdk bot commented Jun 2, 2021

@wangweij this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout 8267521
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk
Copy link

@openjdk openjdk bot commented Jun 2, 2021

@wangweij This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8267521: Post JEP 411 refactoring: maximum covering > 50K

Reviewed-by: dfuchs, prr

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 3 new commits pushed to the master branch:

  • 4767758: 8267920: Create separate Events buffer for VMOperations
  • dc19bac: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes
  • 2963c9e: 8268103: JNI functions incorrectly return a double after JDK-8265836

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added ready and removed merge-conflict labels Jun 2, 2021
@wangweij
Copy link
Contributor Author

@wangweij wangweij commented Jun 2, 2021

/integrate

@openjdk openjdk bot closed this Jun 2, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jun 2, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 2, 2021

@wangweij Since your change was applied there have been 4 commits pushed to the master branch:

  • 40d23a0: 8267543: Post JEP 411 refactoring: security
  • 4767758: 8267920: Create separate Events buffer for VMOperations
  • dc19bac: 8268094: Some vmTestbase/nsk tests fail after ACC_STRICT/strictfp changes
  • 2963c9e: 8268103: JNI functions incorrectly return a double after JDK-8265836

Your commit was automatically rebased without conflicts.

Pushed as commit 508cec7.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@wangweij wangweij deleted the 8267521 branch Jun 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment