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][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:

        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.


[jig]: http://openjdk.java.net/projects/jigsaw/