Draft JEP for discussion: Lint and doclint clean sources

[Joe Darcy]

Hello,

To formalize previously discussed efforts to cleanup the lint warnings 
on the JDK's sources, I've written up a draft JEP:

     JDK-8042878 Lint and doclint clean sources
     https://bugs.openjdk.java.net/browse/JDK-8042878

and am soliciting comments. For convenience, the text of the JEP is below.

Thanks,

-Joe


Summary

The JDK code base contains numerous lint and doclint errors as reported 
by javac. These warnings should be resolved, at least for the 
fundamental parts of the platform.


Goals

Operationally, the goal is to have at least the packages for the 
fundamental packages in the platform (those discussed on core-libs, 
awt-dev, swing-dev, 2d-dev, etc.) compile cleanly under javac's lint and 
doclint warnings. It is desirable for other packages, such as those 
comprising jaxp, jax-ws, and corba to also compile cleanly with all 
warning enabled.


Success Metrics

A successful build of the sources in question when the -Xlint:all option 
is used for the javac command. A slightly weaker goal that may be 
acceptable is for all the source-related lint options to be enabled, but 
not the lint options for non-source properties. For example, some lint 
options concern properties of the javac command line rather than the 
sources being compiled.


Description

This JEP proposes to complete efforts to fix warnings that have been 
underway in JDK 8 and JDK 9 as well as to formalize a subset of source 
code improvements previously proposed to jdk9-dev. Most of the warnings 
are resolved by modifying the interior of method bodies. Resolving some 
of rawtypes warnings involves changing method signatures, such as 
changing a parameter type from a raw java.lang.Class to a 
java.lang.Class or some more specific type. Any API changes will stay 
within the general evolution policy of the JDK.


Testing

A successful compile / build is the primary test for most changes, but 
the existing regression tests should continue to pass. Where a Java SE 
API has a signature change, the corresponding JCK signature test will 
need to be updated accordingly.


Dependences

Resolving the deprecation warnings in the JDK would be eased if 
importing a deprecated type does not trigger a deprecation warning.