Draft JEP for discussion: Lint and doclint clean sources

[Martijn Verburg]

Looks good Joe,

One quick Q:  In your guide you talk about "Avoid introducing source
incompatibilities<http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#source_compatibility>".
 Is there a possibility that adding Generics in order to fix a linting
problem would break this guideline?

Cheers,
Martijn


On 28 May 2014 01:04, Joe Darcy <joe.darcy at oracle.com> wrote:

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