JDK-8032211 : Don't issue deprecation warnings on import statements
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-01-18
  • Updated: 2017-05-17
  • Resolved: 2014-11-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b42Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8065613 :  
Description
During efforts to rid the JDK code base of lint warnings, it has been observed that the deprecation lint warnings currently issued on import statements are a nuisance and often uninformative.

While use of deprecated types within methods or in method signatures can be suppressed using @SuppressWarning, and annotation *cannot* be used to suppress the deprecation warning on an import. To get a warning-free program that must use deprecated types or method, it is unreasonable to impose a requirement that all references to the deprecated elements must be through a fully qualified name.

Therefore, it would be helpful if the JLS were changed to no longer require a deprecation warning be used for import statements.
Comments
From http://mail.openjdk.java.net/pipermail/compiler-dev/2014-October/009069.html Great feedback. I think the import of non-deprecated static members of a deprecated type should continue to generate warnings, so that the use-by-simple-name of the imported static members continues to _not_ generate warnings. It looks like we want to distinguish: import z.Bar; // No warning please, because simple uses of Bar get warnings (unless suppressed). from: import [static] z.Bar.$MEMBER; // Warning please, because simple uses of $MEMBER don't get warnings. That is possible by sharpening the proposed spec change from: * The use is within an import statement. to: * The use is within an import statement that imports the type or member whose declaration is annotated with @Deprecated. To be clear, 'import z.Bar.B;' contains a use of the deprecated type Bar, and the use is NOT within an import statement importing the @Deprecated Bar, so the warning is NOT turned off. For completeness, suppose B's declaration is made @Deprecated, and Bar's declaration is still @Deprecated. 'import z.Bar.B;' contains a use of the deprecated type Bar, and the logic above still applies (warning NOT turned off) ... it also contains a use of the deprecated member B within an import statement importing that very member B, so the warning IS turned off. But don't worry - now that B's declaration is @Deprecated, the simple name 'B' throughout Foo will give a warning.
22-10-2014

From JLS 7, 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." http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.6 The specification change would be something like adding another bullet * The use is within an import statement.
18-01-2014