Draft JEP: Elide deprecation warnings on import statements
Joe Darcy
joe.darcy at oracle.com
Wed Feb 5 12:20:01 PST 2014
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.
More information about the compiler-dev
mailing list