- GETTING STARTED
- BASIC JAVA
- JAVA STRINGS
- EXCEPTION HANDLING
- JAVA 9
- EFFECTIVE JAVA
The main goal of this JEP(JDK Enhancement Proposal) is to extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single archive. It intends to Implement multi-release JAR files in the JRE, including support in the standard class loaders and JarFile API. Enhance other critical tools (e.g., javac, javap, jdeps, etc.) to interpret multi-release JAR files and preserve performance while doing the above.
A JAR file has a content root (containing classes and resources) and a META-INF directory. This contains metadata about the JAR.
JEP 238 aims to extend the JAR file format in Java 9.
A JAR contains a root directory where all its contents reside. It contains a META-INF directory that is used to store metadata about the JAR. Typically, a JAR contains a META-INF/MANIFEST.MF file containing its attributes. Entries in a typical JAR look like this:
- jar-root - Class1.class - Class2.class - Class3.class - META-INF - MANIFEST.MF
A MRJAR(Multi-Release JAR Files) extends the already existing directory structure for a JAR by allowing multiple, Java-release-specific versions of class/resource files to coexist in the same archive.
A MRJAR extends the META-INF directory to store classes that are specific to a JDK version. The META-INF directory contains a versions sub-directory, which may contain many sub-directories—each of them named the same as the JDK major version.
For example, for classes specific to JDK 9, there may be the META-INF/versions/9 directory and, for classes specific to JDK 10, there may be a directory called META-INF/versions/10, etc. A typical MRJAR may have the following entries:
- jar-root - Class1.class - Class2.class - Class3.class - META-INF - versions - 9 - Class2.class -10 - Class2.class - Class3.class - MANIFEST.MF
Now you might ask what happens when MRJAR is used in an environment that does not support MRJARs. In that case it will be treated as a regular JAR—the contents in the root directory will be used and all other contents in META-INF/versions/9 and META-INF/versions/10 will be ignored.
So, if this MRJAR is used with JDK 8, first three classes will be used. And when this MRJAR is used in JDK 9, the Class2 class in the META-INF/versions/9 directory will be used instead of the Class2 class from the root directory. In this case, the MRJAR is saying that it has a newer version of the Class2 class for JDK 9 that overrides the version of Class2 in the root directory that is for JDK 8 or earlier.
By this scheme, it is possible for versions of a class designed for a later Java platform release to override the version of that same class designed for an earlier Java platform release.