Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8042566

JEP 211: Elide Deprecation Warnings on Import Statements

    Details

    • Author:
      Joseph D. Darcy
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
    • Scope:
      SE
    • Discussion:
      compiler dash dev at openjdk dot java dot net
    • Effort:
      S
    • Duration:
      M
    • Alert Status:
       Green
    • JEP Number:
      211

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                darcy Joe Darcy
                Reporter:
                darcy Joe Darcy
                Owner:
                Joe Darcy
                Reviewed By:
                Brian Goetz
                Endorsed By:
                Brian Goetz
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved:
                  Integration Due: