Draft JEP: Elide deprecation warnings on import statements

[Stephen Colebourne]

This happens in pretty much all large codebases over time and would be
a welcome change IMO.
Stephen

On 5 February 2014 20:20, Joe Darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
> Below is the text of a draft JEP we are considering submitting for JDK 9.
>
> Cheers,
>
> -Joe
>
>
> Summary
> -------
>
> As of Java SE 8, java compilers are required by reasonable
> interpretations of the Java Language Specification to issue
> deprecation warnings when a deprecated type is imported by name or
> when a deprecated member (method, field, nested type) is imported
> statically. These warnings are uninformative and should not be
> required. Deprecation warnings at actual uses of deprecated members
> should remain.
>
> Goals
> -----
>
> The goal of this JEP is to facilitate making large code bases clean of
> lint warnings. The deprecation warnings on imports cannot be
> suppressed using the @SuppressWarnings annotation, unlike uses of
> deprecated members in code. In large code bases like that of the JDK,
> deprecated functionality must often be supported for some time and
> merely importing a deprecated construct does not justify a warning
> message if all the uses of the deprecated construct are intentional
> and suppressed.
>
> Non-Goals
> ---------
>
> It is not a goal of this JEP to actually resolve all the deprecation
> warnings in the JDK code case. However, that might occur as part of a
> separate maintenance effort in JDK 9.
>
> Description
> -----------
>
> From a specification perspective, the needed change is small. In JLS 7
> (text in JLS 8 will be similar), the section on @Deprecated states:
>
> "A Java compiler must produce a deprecation warning when a type,
> method, field, or constructor whose declaration is annotated with the
> annotation @Deprecated is used (i.e. overridden, invoked, or
> referenced by name), unless:
>
>     * The use is within an entity that is itself annotated with the
>       annotation @Deprecated; or
>
>     * The use is within an entity that is annotated to suppress the
>       warning with the annotation @SuppressWarnings("deprecation"); or
>
>     * The use and declaration are both within the same outermost class."
>
> The specification change would be something like adding another bullet
> stating the additional exclusion:
>
>     * The use is within an import statement.
>
> In the javac reference implementation, there would be a simple check
> to skip over import statements when looking for deprecation warnings.
>
> Testing
> -------
>
> Normal unit tests should suffice to test this feature. A handful of
> JCK tests may need to be updated for the changed specification.
>
> Impact
> ------
>
>   - Other JDK components: The change would ease getting and keeping
>      the JDK code base free of deprecations warnings.
>   - Compatibility: Since warning will be issued in fewer cases, there is
> negligible compatibility impact.
>   - User experience: Fewer uninformative warnings will be issued by the
> compiler.
>   - TCK: As noted earlier, a handful of JCK test may need updating.
>