JDK-8042566 : JEP 211: Elide Deprecation Warnings on Import Statements
  • Type: JEP
  • Component: tools
  • Sub-Component: javac
  • Priority: P3
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 9
  • Submitted: 2014-05-07
  • Updated: 2021-03-20
  • Resolved: 2015-02-09
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
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 8 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
> `@Deprecated` is used (overridden, invoked, or referenced by name) in a
> construct which is explicitly or implicitly declared, 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.