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][jig] 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 `FactoryFinder`s 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:
- 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
- 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
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.