Summary

Restructure the JDK and JRE run-time images to accommodate modules.

Problem

This is the CCC for JEP 220: Modular Run-Time Images as found here:

   http://openjdk.java.net/jeps/220

A snapshot of the JEP is also attached to this CCC.

Solution

As detailed in the JEP, the solution involves:

1. A new run-time image structure
2. The removal of rt.jar and tools.jar
3. The removal of the endorsed-standards override mechanism
4. The removal of the extension mechanism
5. A new URI scheme for naming stored modules, classes, and resources

Specification

The run-time image structure is as per the JEP. In summary, run-time images will have the following directories:

1. The bin directory will contain any command-line launchers defined by the modules linked into the image. (On Windows it will continue to contain the run-time system's dynamically-linked native libraries.)

2. The conf directory will contain the .properties, .policy, and other kinds of files intended to be edited by developers, deployers, and end users, which were formerly found in the lib directory or subdirectories thereof.

3. The lib directory on Mac OS, or the lib/$ARCH directory on Linux and Solaris, will contain the run-time system's dynamically-linked native libraries, as it does today. These may be linked against by programs that embed the run-time system. All other files and directories in the lib directory must be treated as private implementation details of the run-time system. They are not intended for external use and their names, format, and content will be subject to change without notice.

4. A full JDK image will, additionally, contain the demo, sample, and include directories, as it does today.

To make it easy to tell which modules are present in a run-time image the release file (top-level directory) will be augmented with a new property, MODULES, which will be a space-separated list of the names of those modules.

The specdiffs with the Java SE API and javadoc changes are attached to this CCC as jep220-apidiffs.html.

In summary:

• java.lang.System.getProperties is updated to drop java.ext.dirs from the list of system properties.

• 3 fields in java.util.jar.Attributes.Name are deprecated. Note that these fields are planned to be deprecated in a MR of JSR 337 (see CCC-8065702) so this is technically not a change in Java SE 9.

• The location of jndi.properties referenced in javax.naming.Context is downgraded from normative to non-normative and changed from ${java.home}/lib to ${java.home}/conf. The downgrading of the reference to non-normative was originally intended to be done as part of JEP 162 but didn't get done in time for Java SE 8.

• The normative references to ${java.home}/lib/jaxp.properties in java.xml.** are changed to ${java.home}/conf/jaxp.properties. A future CCC may downgrade these references to non-normative. The downgrading was not done as part of JEP 162 because JAXP was a standalone JSR at the time.

• Several references to the extensions mechanism and extensions directory have been removed. We do not believe that the change to javax.script.ScriptEngineManager requires a MR of JSR 233.

• Several non-normative references to configuration files in ${java.home}/lib have been changed to ${java.home}/conf.

The Endorsed-Standards Override Mechanism is removed.

The runtime will refuse to start if ${java.home}/lib/endorsed exists or the system property java.endorsed.dirs is specified on the command line.

javac -endorseddirs (and -Djava.endorsed.dirs) will be restricted to -target <= 8 at a later time.

See CCC-8065675 with the proposal to deprecate this mechanism in 8uX.

The mechanism that we know as the Extensions Mechanism is removed. More specifically the concept of "optional packages" is removed in Java SE 9. The definition and discovery of installed optional packages is not supported; instead, shared code should be delivered as a module so that it can be linked into a modular run-time image. JAR files can continue to require other JAR files via the Class-Path attribute, but the required JAR files are no longer referred to as download optional packages or bundled optional packages.

Here are the relevant features of Java SE 8 which are proposed to not exist in Java SE 9:

1. The concept of an installed optional package. Specifically:

   • The Extension-Name attribute in the JAR File Specification, for declaring a JAR as an installed optional package.

   • The java.ext.dirs system property for specifying the location of installed optional packages. The runtime will refuse to start if ${java.home}/lib/ext exists or the system property java.ext.dirs is specified on the command line.

2. The ability of a JAR-packaged applet to depend on an installed optional package. Specifically:

   • The Extension-List and -Extension-Name attributes in the JAR File Specification, for specifying the installed optional packages required by the applet.

3. The ability of a JAR-packaged applet to trigger downloading of optional packages. Specifically:

   • The -Specification-Version and -Implementation-* attributes in the JAR File Specification, for specifying certain details of installed optional packages required by the applet.

   • The ability of the applet context to download a new version of an installed optional package.

   • The ability of the applet context, under some circumstances, to install the new version into the java.ext.dirs location.

   • The Extension-Installation attribute in the JAR File Specification, for specifying a native application to help install the new version.

4. The concept of a download optional package (a.k.a. bundled optional package) which is private to an application rather than available to all applications (per installed optional packages).

Other features of Java SE 8 are associated with optional packages will continue to exist in Java SE 9, as follows:

1. The Class-Path attribute in the JAR File Specification, for specifying JAR files required by another JAR file.

2. Versioning of packages and JAR files, via the {Specification,Implementation}-{Title,Version,Vendor} attributes in the JAR File Specification.

3. Sealing of packages and JAR files, via the Sealed attribute in the JAR File Specification.

4. The Extension Class Loader, previously responsible for defining classes for installed optional packages. The extension class loader will continue to load classes for several modules in the run-time image (typically modules that do not require all permissions and modules that are service providers).

The spec diffs for the proposed changes to the JAR file specification are attached to this CCC as jep220-jardiffs.html. The sections entitled Class-Path Attribute and Sealing Packaging were previously in the Extension Mechanism Architecture document.

See CCC-8065702 where this mechanism is proposed to be deprecated in a MR of JSR 337.

The final part to extension mechanism is the tools/command line options:

1. javac -extdirs (and  -Djava.ext.dirs) will be restricted to -target <= 8 at a later time.

2. rmic -extdirs is removed.

In CCC-8042888 then the extcheck tool is removed.

As outlined in JEP 220, a new JDK-specific jrt URI scheme is proposed and it is also proposed to include a built-in NIO FileSystemProvider for the jrt URL scheme. More details on the FileSystemProvider are included here:

1. A call to java.nio.file.FileSystems.getFileSystem(URI.create("jrt:/")) will return a read-only FileSystem that may be used to access the stored modules, and class and resources files in the current run-time using file paths.

2. Tools running on JDK 8 may add $JDK9/jrt-fs.jar to their class path and use FileSystems.newFileSystem(URI.create("jrt:/"), null) to create a FileSystem that provides access to the contents of the JDK 9 image.

Alternatively, tools on JDK 8 may create a URLClassLoader with a URL to the target image jrt-fs.jar and specify that class loader to FileSystems.newFileSystems to create a FileSystem to access the target image.

A future CCC may re-visit this solution to provide wider support for interoperability between JDK versions. It may also provide a mechanism for tools that are not module-aware to access class and resources without needing the module name in the file path.

1. A jrt file system uses / as the file separator in file paths. It has one top-level root directory '/'. The default directory for jrt file systems is also '/'.

2. As outlined in the JEP, the names of the entries in the top-level directory of the jrt file system are the module names and beneath the module names in the file system is a directory structure that mirrors the package structure.

This CCC proposes to include a new tool named jimage in the bin directory of the JDK image. The purpose of the tool is to aid troubleshooting and to allow for tools that do static instrumentation of classes in the run-time image (jcov for example). The jimage tool proposed for JDK 9 currently supports options to list, extract or recreate a jimage file. The tool is not intended to be a fully-functional equivalent to the jar tool and is not intended to be documented or be a supported interface.

As part of JEP 161 (Compact Profiles), the "java -version" output of compact profiles builds included the profile name (CCC-8003256). This CCC proposes to drop this so that "java -version" does not include the profile name. A future CCC may also drop the JAVA_PROFILE key from the release file.

As noted in the open issues section of JEP 220, "some changes to how fonts are configured may yet be required". This issue is a reference to font configuration files and binary font files copied into ${java.home}/lib as detailed in CCC-4097028 and CCC-4833104

A replacement and supportable solution to allow for font configuration may be the subject of a future CCC.

As noted in JEP 220, builds of the the JRE will now include a few additional tools/commands:

   appletviewer
   idlj
   java-rmi.cgi (java-rmi.exe)
   jrunscript
   jstatd

Future CCCs may re-visit this, for example java-rmi is legacy and may be removed in JDK 9.

Another consequence of generating run-time images from a set of modules is that Oracle builds of the JRE build include both the client and server VM on 32-bit platforms. This is a change on Windows 32-bit where the JRE has historically only included the client VM.