Details

    • Compatibility Risk:
      high
    • Compatibility Risk Description:
      Hide
      The compatibility risk is high as this is a significant change that we know will impact a number of high profile tools and some applications and libraries.

      The following is the list of compatibility concerns listed in the JEP :

      1. A JDK image will no longer contain a jre subdirectory. Existing code that assumes the existence of that directory might not work correctly.

      2. JDK and JRE images will no longer contain the files lib/rt.jar and lib/tools.jar. Existing code that assumes the existence of these files might not work correctly.

      3. The Endorsed-Standards Override Mechanism and Extension Mechanism are removed and the system properties java.endorsed.dirs and java.ext.dirs will no longer be defined. Existing code or deployments that rely on these mechanisms or assume these properties to have non-null values might not work correctly. The -XX:+CheckEndorsedAndExtDirs option proposed for 7uX and 8uX in CCC-8064667 provides a means to help determine if an application is making use of these mechanisms.

      4. Existing standard APIs that return URL objects to name class and resource files inside the run-time image will now return jrt URLs. Existing code that expects these APIs to return jar URLs might not work correctly.

      5. The internal system property sun.boot.class.path will no longer name a sequence of jar files and directories. Existing code that depends upon this property might not work correctly.

      6. Class and resource files previously found in lib/tools.jar and visible only when that file was added to the class path will now, in a JDK image, be visible via the system class loader or, in some cases, the bootstrap class loader. The modules containing these files will not, however, be mentioned in the application class path, i.e., in the value of the system property java.class.path.


      In addition to the risks/compatibility concerns listed in the JEP, we note here a few additional behavioral changes:

      1. The defining class loader for a number of types is changed and so existing code that makes assumptions on the defining loader may not work correctly. This change is a consequence of modularization of components that contain tools and where the runtime and tool classes for components were previously split between rt.jar and tools.jar. For completeness we list the API packages of the types where the defining class loader changes:

         com.sun.crypto : extension class loader => boot class loader
         com.sun.tools.corba.se.idl : application class loader => boot class loader
         com.sun.tools.script : application class loader => boot class loader
         com.sun.jndi.dns : boot class loader => extension class loader
         com.sun.jndi.url.dns : boot class loader => extension class loader
         com.sun.tracing : boot class loader => application class loader
         sun.security.tools.policytool : boot class loader => application class loader
         sun.tools.jar : boot class loader => application class loader
         sun.tracing.dtrace : boot class loader => application class loader

      2. The javax.swing.*BeanInfo classes that were previously in dt.jar and only shipped with the JDK are now visible via the boot class loader and included in both the JRE and JDK. A future CCC may eliminate the static generation of the BeanInfo classes (see CCC-4058433).


      Significant documentation updates, compatibility guide and release notes are planned for this feature.
      Show
      The compatibility risk is high as this is a significant change that we know will impact a number of high profile tools and some applications and libraries. The following is the list of compatibility concerns listed in the JEP : 1. A JDK image will no longer contain a jre subdirectory. Existing code that assumes the existence of that directory might not work correctly. 2. JDK and JRE images will no longer contain the files lib/rt.jar and lib/tools.jar. Existing code that assumes the existence of these files might not work correctly. 3. The Endorsed-Standards Override Mechanism and Extension Mechanism are removed and the system properties java.endorsed.dirs and java.ext.dirs will no longer be defined. Existing code or deployments that rely on these mechanisms or assume these properties to have non-null values might not work correctly. The -XX:+CheckEndorsedAndExtDirs option proposed for 7uX and 8uX in CCC-8064667 provides a means to help determine if an application is making use of these mechanisms. 4. Existing standard APIs that return URL objects to name class and resource files inside the run-time image will now return jrt URLs. Existing code that expects these APIs to return jar URLs might not work correctly. 5. The internal system property sun.boot.class.path will no longer name a sequence of jar files and directories. Existing code that depends upon this property might not work correctly. 6. Class and resource files previously found in lib/tools.jar and visible only when that file was added to the class path will now, in a JDK image, be visible via the system class loader or, in some cases, the bootstrap class loader. The modules containing these files will not, however, be mentioned in the application class path, i.e., in the value of the system property java.class.path. In addition to the risks/compatibility concerns listed in the JEP, we note here a few additional behavioral changes: 1. The defining class loader for a number of types is changed and so existing code that makes assumptions on the defining loader may not work correctly. This change is a consequence of modularization of components that contain tools and where the runtime and tool classes for components were previously split between rt.jar and tools.jar. For completeness we list the API packages of the types where the defining class loader changes:    com.sun.crypto : extension class loader => boot class loader    com.sun.tools.corba.se.idl : application class loader => boot class loader    com.sun.tools.script : application class loader => boot class loader    com.sun.jndi.dns : boot class loader => extension class loader    com.sun.jndi.url.dns : boot class loader => extension class loader    com.sun.tracing : boot class loader => application class loader    sun.security.tools.policytool : boot class loader => application class loader    sun.tools.jar : boot class loader => application class loader    sun.tracing.dtrace : boot class loader => application class loader 2. The javax.swing.*BeanInfo classes that were previously in dt.jar and only shipped with the JDK are now visible via the boot class loader and included in both the JRE and JDK. A future CCC may eliminate the static generation of the BeanInfo classes (see CCC-4058433). Significant documentation updates, compatibility guide and release notes are planned for this feature.
    • Interface Kind:
      Java API, add/remove command in $JDK/bin, add/remove/modify command line option, Other
    • Scope:
      SE

      Description

      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.

        Attachments

        1. jep220.html
          53 kB
        2. jep220-apidiffs.zip
          7.58 MB
        3. jep220-jardiffs.zip
          60 kB

          Issue Links

            Activity

              People

              • Assignee:
                alanb Alan Bateman
                Reporter:
                alanb Alan Bateman
                Reviewed By:
                Alex Buckley, Mandy Chung
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: