Details
-
Enhancement
-
Resolution: Unresolved
-
P3
-
9
Description
The fix for the previous issue added warnings suppression to source file locations as a quick fix to get the build to be warnings-free. These locations need to be revisited to understand whether the deprecation warnings that were suppressed are actionable.
The subtasks were initially created on a module by module basis and contain lists of deprecation warnings from that module. The subtasks can be split up, rearranged, etc. as necessary to facilitate better handling of the workload.
The warnings contain information about what deprecated API is used and the file and line number of the use site. However, the warnings were generated a few years ago, so it might be difficult to trace the use site mentioned in each warning in the subtask to current location of that use site. A suggested procedure dealing with this situation is as follows:
1) For each source file listed in the subtask, comment out the @SuppressWarnings("deprecation") annotation.
2) Compile with a command like
make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
and capture the output in a log file. (This exact command might not work. To adjust the javac flags used in the build, look in the file $ROOT/make/common/SetupJavaCompilers.gmk)
3) For each warning issued, assess the deprecated API being warned about, and determine a plan for handling it. In some cases, code should be migrated to use a different API. In other cases, there may be no choice but to leave the warning suppressed.
4) If there are code changes, follow the usual JDK procedure for building, testing, reviewing, etc. and push the changeset using the subtask's issue ID. If there are no code changes (meaning it's proper to suppress the deprecation warnings) then close the subtask as Not an Issue and add a note to document the results of the analysis.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Open
-