Java 9 : Do you know the following facts ?

Whenever a new version of Java is released, there’s a lot of excited discussion about new language constructs and APIs, features, and benefits. But the excitement quickly wanes for legacy developers when they remember that they must maintain and enhance existing applications, rather than create new ones. Most applications must be backward compatible with earlier versions of Java, which do not support new features presented by shiny new Java releases. Java 9’s designers have worked out ways to make Java 9’s new features accessible for developers who have to worry about their applications supporting older versions of Java.

New features in Java 9 — Multi-Release JAR files, Project Jigsaw (the new module system) — make Java 9 usable and relevant to legacy Java developers.

Multi-Release JAR Files

·Until recently, there hasn’t been a good way to use the latest Java features while still allowing the application to run on earlier versions of Java that don’t support that application. Java 9 finally provides a way to do this for both new APIs and for new Java language constructs: Multi-Release JAR files.

·They look just like old-fashioned JAR files, with one crucial addition: there’s a new nook in the JAR file where you can put classes that use the latest Java 9 features.

·If you’re running Java 9, the JVM recognizes this nook, uses the classes in that nook, and ignores any classes of the same name in the regular part of the JAR file.

·If you’re running Java 8 or earlier, however, the JVM doesn’t know about this special nook and will ignore it, and only run the classes in the regular part of the JAR file.

·In the future, when Java 10 comes out, there’ll be another nook specifically for classes using new Java 10 features, and so forth.

·The Java 9 JDK will contain a version of the jar.exe tool that supports creating multi-release JAR files. Other non-JDK tools will also provide support.

Java 9 Module System : Project Jigsaw

·One goal of modularization is to strengthen Java’s encapsulation mechanism so that the developer can specify which APIs are exposed to other components and count on the JVM to enforce the encapsulation.

·Modularizations encapsulation is stronger than that provided by the public/protected/private access modifiers of classes and class members.

·The second goal of modularization is to specify which modules are required by which other modules and to ensure that all necessary modules are present before the application executes.

·Modules are stronger than the traditional classpath mechanism, since classpaths are not checked ahead of time, and errors due to missing classes only occur when the classes are actually needed, which means that an incorrect classpath might be discovered only after an application has been run for a long time, or after it has been run many times.

·Java 9 offers both a classpath and a module path. The classpath works just as before, and you can keep using it. JAR files in the module path are interpreted as modules — they expose APIs and have dependencies that can be checked at compile time.

·All the JAR files in the classpath are considered part of the unnamed module, which means they become part of the module system, too.

Read more at http://openjdk.java.net/projects/jigsaw/spec/sotms/