JEP 212: Resolve Lint and Doclint WarningsJEP 212: Resolve Lint and Doclint WarningsAuthorJoseph D. DarcyOwnerJoe DarcyTypeFeatureScopeJDKStatusClosed / DeliveredRelease9ComponenttoolsDiscussionjdk9 dash dev at openjdk dot java dot netEffortMDurationLReviewed byBrian GoetzEndorsed byBrian GoetzCreated2014/05/09 21:55Updated2024/02/05 20:31Issue8042878Summary
The JDK code base contains numerous lint and doclint errors as reported
by javac. These warnings should be resolved, at least for the fundamental
parts of the platform.
Goals
Operationally, the goal is to have at least the packages for the
fundamental packages in the platform (those discussed on core-libs,
awt-dev, swing-dev, 2d-dev, etc.) compile cleanly under javac's lint and
doclint warnings. It is desirable for other packages, such as those
comprising JAXP, JAX-WS, and CORBA to also compile cleanly with all
warnings enabled.
Success Metrics
A successful build of the sources in question when the -Xlint:all option
is used for the javac command. A slightly weaker goal that may be
acceptable is for all the source-related lint options to be enabled, but
not the lint options for non-source properties. For example, some lint
options concern properties of the javac command line rather than the
sources being compiled.
Description
This JEP proposes to complete efforts to fix warnings that have been
underway in JDK 8 and JDK 9 as well as to formalize a subset of
source-code improvements previously proposed to jdk9-dev. Most of
the warnings are resolved by modifying the interior of method
bodies. Resolving some of rawtypes warnings involves changing method
signatures, such as changing a parameter type from a raw
java.lang.Class to a java.lang.Class<?> or some more specific
type. Any API changes will stay within the general evolution policy
of the JDK.
Testing
A successful compile / build is the primary test for most changes, but
the existing regression tests should continue to pass. Where a Java SE
API has a signature change, the corresponding JCK signature test will
need to be updated accordingly.
Dependences
Resolving the deprecation warnings in the JDK would be eased
if importing a deprecated type does not trigger a deprecation warning.
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
