2017  Kodetalk | Feedback | Privacy Policy | Terms | About

Java 9 Modular Run-Time Images and structure

Java 9 in Real:

Java 9, restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability.

Basically it does by adopting a run-time format for stored class and resource files that:

Is more time- and space-efficient than the legacy jar format, which in turn is based on the ancient zip format;
Can locate and load class and resource files on a per-module basis;
Can store class and resource files from JDK modules and from library and application modules; and
Can be extended to accommodate additional kinds of data going forward, such as precomputed JVM data structures and precompiled native code for Java classes.

Restructure of JDK and JRE run-time images to draw a clear distinction between files that developers, deployers, and end-users can rely upon and, when appropriate, modify, in contrast to files that are internal to the implementation and subject to change without notice. By providing a supported ways to perform common operations that today can only be done by inspecting the internal structure of a run-time image such as, e.g., enumerating all of the classes present in an image.

Enable the selective de-privileging of JDK classes that today are granted all security permissions but do not actually require those permissions.

Preserve the existing behavior of well-behaved applications, i.e., applications that do not depend upon internal aspects of JRE and JDK run-time images.

The JDK build system presently produces two types of run-time images: A Java Runtime Environment (JRE), which is a complete implementation of the Java SE Platform, and a Java Development Kit (JDK), which embeds a JRE and includes development tools and libraries. (The three Compact Profile builds are subsets of the JRE.)

The root directory of a JRE image contains two directories, bin and lib, with the following content:

The bin directory contains essential executable binaries, and in particular the java command for launching the run-time system. (On the Windows operating system it also contains the run-time system's dynamically-linked native libraries.)

The lib directory contains a variety of files and subdirectories:

Various .properties and .policy files, most of which may be, though rarely are, edited by developers, deployers, and end users;
The endorsed directory, which does not exist by default, into which jar files containing implementations of endorsed standards and standalone technologies may be placed;
The ext directory, into which jar files containing extensions or optional packages may be placed;
Various implementation-internal data files in assorted binary formats, e.g., fonts, color profiles, and time-zone data;
Various jar files, including rt.jar, which contain the run-time system's Java class and resource files.

The run-time system's dynamically-linked native libraries on the Mac OS, Linux, and Solaris operating systems. (In the latter two cases the libraries are placed in the lib/$ARCH subdirectory where $ARCH is the name of the CPU-architecture family supported by the image, e.g., amd64.)

A JDK image includes a copy of the JRE in its jre subdirectory and contains additional subdirectories:

The bin directory contains command-line development and debugging tools, e.g., javac, javadoc, and jconsole, along with duplicates of the binaries in the jre/bin directory for convenience;
The demo and sample directories contain demonstration programs and sample code, respectively;
The man directory contains UNIX-style manual pages;
The include directory contains C/C++ header files for use when compiling native code that will interface directly with the run-time system; and
The lib directory contains various jar files and other types of files comprising the implementations of the JDK's tools, among them tools.jar, which contains the classes of the javac compiler.
The root directory of a JDK image, or of a JRE image that is not embedded in a JDK image, also contains various COPYRIGHT, LICENSE and README files and also a release file that describes the image in terms of simple key/value property pairs, e.g.,


New run-time image structure

The present distinction between JRE and JDK images is purely historical, a consequence of an implementation decision made late in the development of the JDK 1.2 release and never revisited. The new image structure will eliminate this distinction: A JDK image will simply be a run-time image that happens to contain the full set of development tools and other items historically found in the JDK.

A modular run-time image will contain the following directories:

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.)
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.
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.
A full JDK image will, additionally, contain the demo, sample, man, and include directories, as it does today.

The root directory of a modular run-time image will also, of course, contain the necessary COPYRIGHT, LICENSE, README, and release files. To make it easy to tell which modules are present in a run-time image the release file will be augmented with a new property, MODULES, which will be a space-separated list of the names of those modules. The list will be topologically ordered according to the modules' dependence relationships, so the java.base module will always be first.