JEP 162: Prepare for Modularization
|JSR||173 MR, 206 MR, 337|
|RFE||7192274, 8000362, 7190273, 7193339, 7169894, 8003562|
|Discussion||jigsaw dash dev at openjdk dot java dot net|
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.
It is not a goal of this effort to integrate code for the module system, developed in Project Jigsaw, into JDK 8.
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.
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
java.security.Principalas that would eliminate the need for
Review normative specification references to files in
$JAVA_HOMEand 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.
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.
- 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.