跳到主要内容

JEP 162: Prepare for Modularization

Summary​

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.