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

wangweij · 2021-05-21T01:52:27Z

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:

Extract calls into a method and add annotation on that method
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.
Put declaration and assignment into a single statement if possible.
Rewrite code to achieve optimization algorithm：tableSizeFor #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

Daniel Fuchs (@dfuch - Reviewer) ⚠️ Review applies to 60d97a4
Phil Race (@prrace - Reviewer) ⚠️ Review applies to 60d97a4

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 · 2021-05-21T01:52:51Z

👋 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 · 2021-05-21T01:55:05Z

@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 · 2021-05-21T01:58:46Z

Webrevs

dfuch · 2021-05-21T15:35:05Z

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java

+        @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");
                    }


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

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

dfuch · 2021-05-21T15:37:48Z

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java

@@ -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")


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

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.

dfuch · 2021-05-21T15:43:22Z

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java

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

+    @SuppressWarnings("removal")


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

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 · 2021-05-24T20:37:53Z

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". :-(

prrace · 2021-05-27T17:42:56Z

src/java.desktop/share/classes/java/awt/Component.java

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

+        @SuppressWarnings("removal")


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 ?

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.

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 ?

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.

openjdk-notifier · 2021-06-02T11:59:31Z

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 · 2021-06-02T12:00:47Z

@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 · 2021-06-02T15:36:29Z

@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.

wangweij · 2021-06-02T15:46:17Z

/integrate

openjdk · 2021-06-02T15:49:17Z

@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.

openjdk bot added the rfr Pull request is ready for review label May 21, 2021

openjdk bot added 2d [email protected] swing [email protected] security [email protected] serviceability [email protected] jmx [email protected] core-libs [email protected] net [email protected] i18n [email protected] awt [email protected] labels May 21, 2021

dfuch reviewed May 21, 2021

View reviewed changes

dfuch approved these changes May 24, 2021

View reviewed changes

prrace mentioned this pull request May 27, 2021

8266459: Implement JEP 411: Deprecate the Security Manager for Removal #4073

Closed

3 tasks

prrace reviewed May 27, 2021

View reviewed changes

prrace approved these changes May 30, 2021

View reviewed changes

openjdk-notifier bot changed the base branch from pr/4073 to master June 2, 2021 11:59

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Jun 2, 2021

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

fb90a80

wangweij force-pushed the 8267521 branch from 60d97a4 to fb90a80 Compare June 2, 2021 15:34

openjdk bot added ready Pull request is ready to be integrated and removed merge-conflict Pull request has merge conflict with target branch labels Jun 2, 2021

openjdk bot closed this Jun 2, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 2, 2021

wangweij deleted the 8267521 branch June 2, 2021 18:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

wangweij commented May 21, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented May 21, 2021

openjdk bot commented May 21, 2021

mlbridge bot commented May 21, 2021 •

edited

Loading

dfuch May 21, 2021

wangweij May 21, 2021

dfuch May 21, 2021

wangweij May 21, 2021 •

edited

Loading

dfuch May 21, 2021

dfuch left a comment

wangweij commented May 24, 2021

prrace May 27, 2021

wangweij May 28, 2021

prrace May 28, 2021

wangweij May 28, 2021

openjdk-notifier bot commented Jun 2, 2021

openjdk bot commented Jun 2, 2021

openjdk bot commented Jun 2, 2021 •

edited

Loading

wangweij commented Jun 2, 2021

openjdk bot commented Jun 2, 2021

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

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

Conversation

wangweij commented May 21, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented May 21, 2021

openjdk bot commented May 21, 2021

mlbridge bot commented May 21, 2021 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wangweij May 21, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dfuch left a comment

Choose a reason for hiding this comment

wangweij commented May 24, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openjdk-notifier bot commented Jun 2, 2021

openjdk bot commented Jun 2, 2021

openjdk bot commented Jun 2, 2021 • edited Loading

wangweij commented Jun 2, 2021

openjdk bot commented Jun 2, 2021

wangweij commented May 21, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented May 21, 2021 •

edited

Loading

wangweij May 21, 2021 •

edited

Loading

openjdk bot commented Jun 2, 2021 •

edited

Loading