JDK-8267432 : Refactoring deprecated calls to make @SuppressWarning more precise after JEP 411
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-05-19
  • Updated: 2022-06-08
  • Resolved: 2021-07-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18Fixed
Related Reports
Relates :  
JDK-8264713 - JEP 411: Deprecate the Security Manager for Removal
Sub Tasks
JDK-8267521 :  
Post JEP 411 refactoring: maximum covering > 50K - Resolved
JDK-8267543 :  
Post JEP 411 refactoring: security - Resolved
JDK-8269409 :  
Post JEP 411 refactoring: core-libs with maximum covering > 10K - Resolved
JDK-8270859 :  
Post JEP 411 refactoring: client libs with maximum covering > 10K - Resolved
Description
JDK-8266459 deprecated the Security Manager for removal and added hundreds of `@SuppressWarnings("removal")` all around JDK. In some cases, the annotation must be added to a place which is quite faraway from where the deprecated API is called (For example, if the API is called in a static block and not in a declaration, the annotation must be added to the class level). It is not obvious what the annotation is for, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

Overall, there are two ways to refactor existing code to avoid this:

1. Call the deprecated API in a declaration statement. Sometimes this means a temporary or useless variable must be declared.

2. Extract the call into a separate method

During the automatic conversion, we have a full list of the distance between where each annotation is added and where the deprecated API it guards is. Sub-tasks will be created in this issue to deal with them area by area. Those cases with the longest distance will be considered first.
Comments
All subtasks integrated.
27-07-2021
A more comprehensive data file is uploaded to http://cr.openjdk.java.net/~weijun/jep411/all.html.
11-06-2021
Uploaded "allfixes.txt" containing the analysis of all deprecated API calls in JEP 411. For example, the first section is: ======== open/src/java.desktop/share/classes/java/awt/Component.java:383038 ======== - Line 8996 uses AccessController, annotate at method Component::readObject line 8990, 162 chars ahead of usage, covering 4849 chars - Line 6255 uses AccessController, annotate at VarDef enabled line 6255, 31 chars ahead of usage, covering 198 chars - Line 1429 uses AccessController, annotate at VarDef pi line 1429, 30 chars ahead of usage, covering 199 chars - Line 976 uses AccessControlContext, annotate at method ::getAccessControlContext line 976, 7 chars ahead of usage, covering 137 chars - Line 714 uses AccessControlContext, annotate at method Component::getAccessControlContext line 714, 6 chars ahead of usage, covering 202 chars - Line 629 uses AccessController, annotate at VarDef s line 629, 24 chars ahead of usage, covering 106 chars - Line 508 uses AccessControlContext, annotate at VarDef acc line 508, 27 chars ahead of usage, covering 83 chars - Line 509 uses AccessController, annotate at VarDef acc line 508, 62 chars ahead of usage, covering 83 chars Line 633 uses AccessController, annotate at class line 217, 11707 chars ahead of usage, covering 383038 chars Here, the last line means AccessController is used on line 633, and an annotation must be added on line 217 on class level to suppress it. This class definition covers 383038 chars. Each other line starting with "-" also matches a deprecated API usage and an annotation to suppress it, but the annotation was not actually added in JDK-8266459 because the last annotation has already "shadowed" all of them. If you want to refactor line 633 to avoid the class level annotation, some of these "shadowed" annotations will need to be added back. The whole file is ordered (reversely) by the maximum number of covered chars. So it makes sense to fix from top to bottom. ATTENTION: the data is generated before automatic annotating in JDK-8266459, so the line number might be a little different after that change. The difference should not exceed the number of actual annotations added. So for the example above, the difference is only 1. This should not be a problem if we mainly focus on those changes with a single class-level annotation.
21-05-2021