Project Jigsaw: Modularization Dashboard

This page contains the list of outstanding work required to modularize the JDK.

See the module-system dashboard for tasks related to the module system itself.

Static Modularization

This table lists the areas where changes are required to allow the desired modules to be packaged appropriately, essentially the module graph.

Many of the items in this table also need to be addressed as part of the Compact Profiles (JEP 161) proposal.

Area Description Status Last Update
Core Libraries

java.util.logging.LogManager dependency on java.beans.PropertyChangeListener

java.util.jar.Pack200 dependency on java.beans.PropertyChangeListener

The plan is to (a) Deprecate the 6 methods in JDK 8 with a warning that they will be removed, and (b) Remove the methods in JDK 9.

Status: Problematic methods have been deprecated in JDK 8.

Management JMX Remote API dependency on RMI-IIOP protocol.

The IDL Mapping specification requires that the CORBA Tie classes be in The result is that remote management (without CORBA) is not possible without splitting this package between two modules (management and management-iiop in the current Jigsaw prototype).

For JDK 8 the tentative plan is to change the JSR-160 specification so that the RMI-IIOP transport is optional. The JMX Remote API is proposed to be included in compact3 without CORBA. RMI-IIOP will be present in the full JRE along with CORBA.

Further discussion is required for JDK 9, options include

  • Drop support for RMI-IIOP from this API (removes problematic tie/stub classes)
  • Leave problematic tie/stub classes in the management module and make use of scopes so the management module "requires corba for reflection"
  • Allow for alternative implementations of the management module

Status: Spec changes to the JMX Remote API to allow the IIOP transport be optional have been pushed to JDK 8.

Networking dependency on

This causes a dependency from the base module to the jdk.tls module.

Potential solution is to include TLS in the base module. An alternative proposal is to use a scoped declaration so that the base module has a compile time dependency on the TLS module. 2012/9/19
Core Libraries java.util.Properties dependency on XML parser

Status: A small footprint XML parser based on the JSR-280 RI has been pushed to JDK 8 for use by java.util.Properties.

Security dependency on

This dependency forces to be split between modules.

Status: A proposal to add an "implies" method to is currently in review on security-dev. As part of this then the dependency on has been removed. 2013/01/07
Security dependency on Swing classes The tentative plan for this one is:
  • Deprecate in JDK 8.
  • Remove this class in JDK 9.

Status: DialogCallbackHandler has been deprecated in JDK 8.


DefaultMXBeanMappingFactory dependency on java.beans.ConstructorProperties

This dependency has been eliminated in JDK 8, see 7193302

Client javax.swing BeanInfo classes in dt.jar

See 7179078 for more details.

JAXP Change JAXP specification to allow the API be used without requiring validating parsers, xpath, etc. installed.

Preliminary changes to the specification prepared but there is a lot of implementation work required.

In light of the Profiles work with JAXP in compact2 then we need to re-evaluate whether this effort is absolutely necessary as it is a significant project.


All debugging, serviceability and profiling tools are currently in the module. This is too coarse grain for embedded environments.

The main work required here is likely to be in SA due to the GUI tools.


Dynamic Modularization

This table lists the areas where more in-depth analysis and changes are required to allow these areas run in module mode.

A complete audit of all code and specifications that relate to dynamic class loading needs to be done. That audit will likely result in additional areas being added to this table.

See JDK Modularization Tips for issues to consider.

Area Description Status Last Update

Requires a detailed analysis but MBean class loading, default loader repository and all class loading usages (both spec and implementation) need to be examined.

Auditing of spec/implementation under way 2012/9/7

An analysis of the Java Object Serialization Specification, and the APIs for serialization defined in, is required in order to determine if and how Java Object Serialization can or should work with modules.

See Serialization Notes with some initial notes on this topic.

Not assigned 2012/11/8

RMI is based on Java Object Serialization and furthermore supports dynamic class loading. An in-depth analysis is required to understand if and how RMI will work in module mode.

Not assigned 2012/11/8

CORBA needs to be analyzed to see if any changes will be required to work in module mode. Minimally we know that ORB.create_impl requires changes to load the ORB implementation will the appropriate class loader.

RMI-IIOP also requires in-depth analysis to determine if anything beyond support for serialization in module mode is required.

Not assigned 2012/11/8

Update JAXP to use ServiceLoader. This will require a JCP MR as there are small specification changes required.

This work has been split into six areas and is currently in review on the core-libs-dev list.


Update JAX-WS, JAXB and SAAJ to use ServiceLoader; will likely require MR for all 3.

JAX-WS project has plans to do this 2102/9/7
Client area

This includes AWT, 2D, Swing, JavaBeans JavaSound, image I/O and all other areas in "client". This is mostly an audit of code that uses Class.forName, ServiceLoader or otherwise makes assumptions on class loading with fixes so that this code works in module mode. Some small specification changes are expected.

Not assigned 2012/9/7

JDBC will likely require API changes, in particular for cases such as using a system property to specify the JDBC driver class. Some other minor changes expected, for example the code assumes that the rowset RI is loaded by the same class loader as the rowset API.

Not assigned 2012/9/7