JEP 211: Elide Deprecation Warnings on Import StatementsJEP 211: Elide Deprecation Warnings on Import StatementsAuthorJoseph D. DarcyOwnerJoe DarcyTypeFeatureScopeSEStatusClosed / DeliveredRelease9Componenttools / javacDiscussioncompiler dash dev at openjdk dot java dot netEffortSDurationMReviewed byBrian GoetzEndorsed byBrian GoetzCreated2014/05/07 00:45Updated2021/03/20 00:37Issue8042566Summary
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.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
