JEP 162: Prepare for ModularizationJEP 162: Prepare for ModularizationOwnerAlan BatemanTypeFeatureScopeSEStatusClosed / DeliveredRelease8JSRs173 MR, 206 MR, 337Discussionjigsaw dash dev at openjdk dot java dot netEffortMDurationMBlocksJEP 179: Document JDK API Support and StabilityRelates toJEP 220: Modular Run-Time ImagesEndorsed byMark ReinholdCreated2012/08/31 20:00Updated2017/06/14 20:12Issue8046152Summary
Undertake changes to smooth the eventual transition to modules in a
future release, provide new tools to help developers prepare for the
modular platform, and deprecate certain APIs that are a significant
impediment to modularization.
Non-Goals
It is not a goal of this effort to integrate code for the module system,
developed in Project Jigsaw, into JDK 8.
Description
In light of the deferral of Project Jigsaw to a later release,
this JEP proposes the following changes:


Address class-loading assumptions --- There are several places in the
code base that make assumptions on class loading. Many issues have
already been identified and fixed in Project Jigsaw. As part of
preparing for modules then a wider audit of the code base is proposed
and where possible fixed in JDK 8 so that this code will not need to
be changed again when we move to modules.


Use ServiceLoader --- There are several APIs in the JDK that have
their own service provider mechanism rather than using
java.util.ServiceLoader. The various FactoryFinders in JAXP are
one example. These provider loading mechanisms are problematic for
modules because they are non-standard. We propose to change these
APIs to use java.util.ServiceLoader. In some cases it may be
necessary to make minor changes to the relevant specifications.


Provide a command-line tool in the JDK so that developers can
understand the static dependencies of their applications and
libraries --- As part of Project Jigsaw, a useful class analyzer was
developed that makes it very easy to identify the dependencies. This
class analyzer will be modified to make it easy to identify the usage
of non-standard and JDK internal APIs and would provide a useful
complement to the warnings emitted by javac when compiling code that
make use of JDK internal APIs.


Deprecate Java SE APIs that will be significant impediment to
modularization --- These APIs will be deprecated with a view to their
outright removal when a module system is introduced.  The list of
methods that we currently plan to deprecate are:
java.util.logging.LogManager.addPropertyChangeListener
java.util.logging.LogManager.removePropertyChangeListener
java.util.jar.Pack200.Packer.addPropertyChangeListener
java.util.jar.Pack200.Packer.removePropertyChangeListener
java.util.jar.Pack200.Unpacker.addPropertyChangeListener
java.util.jar.Pack200.Unpacker.removePropertyChangeListener


Deprecate JDK-specific APIs that are a significant impediment to
modularization. At this time the most problematic area is JAAS
where we plan to deprecate the sample callback handler
com.sun.security.auth.callback.DialogCallbackHandler. We may
also explore adding an implies method to java.security.Principal
as that would eliminate the need for
com.sun.security.auth.PrincipalComparator.


Review normative specification references to files in $JAVA_HOME
and where possible downgrade these references to non-normative
status.  By downgrading these references then it will allow their
location (or format) to be changed in a future release. For example
the property file for currencies could be moved into a module-private
location.


Testing
Changing existing APIs to use java.util.ServiceLoader will likely
require the development of new tests.
New command-line tools or runtime options will require new tests.
If a standard PrincipalComparator API is defined then this will require
new conformance and unit tests.
Risks and Assumptions
There is a small risk that changing the implementation, to fix
assumptions related to class loading for example, may cause side
effects. As with all bugs and features then we assume that extensive
testing of JDK 8 will uncover such issues.
Impact

JCK: Changes to specification will likely require updates to conformance
tests for the respected areas.
Compatibility: Deprecating or planning to remove methods or features will
require time to properly analyze the impact.

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
