Version française disponible

Simon Ritter gave a presentation about JDK 9 at QCon London.

Java Compatibility Policy

He started with an interesting fact: Java has a general and longstanding compatibility policy.
If an application uses only supported APIs on version N of Java, it should work on version N+1, even without recompilation.
That’s why, to date there are:

• 23 classes, 18 interfaces and 379 methods that have been deprecated
• And none have been removed.

JDK 9 brings breaking changes

The JDK has been heavier and heavier over the years. With the version 9, things are going to change. For the first time, JDK 9 will bring incompatibilities.

• A small number of supported API will be removed
• The binary structure of the JRE and JDK will change (see details below)
• It is not allowed to use a single underscore _ as a variable name. It is now a reserved keyword.
• There will be a new version scheme so that it is easier to distinguish major, minor, and security-update releases, e.g. Java 9.1.2.1. The old versioning format is difficult to understand, e.g. 8h51 and 8u60 are not very meaningful.

The JDK structure is changing. The JRE folder is removed, tools.jar and rt.jar are no longer present, as there was some duplication between them.

To have a complete understanding of the pre-JDK 9 structure, you can read JDK 8 and JRE File Structure.

The JDK 9 structure is much cleaner.

JEP 260 proposal is at the heart of JDK 9 and Jigsaw.

The idea is to make most of the JDK’s internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality.

The goal is to encapsulate all deprecated API in a module, then eventually getting rid of it in the future (JDK 10?).

Since JDK 8, a command line tool exists to analyze the dependencies of your JAR or class: jdeps. Give it a try! It can be useful to discover if you are using JDK-internal APIs, you should avoid using these dependencies as they may be removed in the future.

Jigsaw and modules

We talk about module just before, but what is it?
Jigsaw brings modularity to the JDK. It makes Java more scalable and flexible, it also improves security, maintainability and performance.
The JDK is split up into modules, and then we take only what we need.

Module

A module is a grouping of code (collection of packages), it can also contain:

• Native code
• Resources
• Configuration data

My first module

To define a module, you need to create a module-info.java file, including (for example):

module com.company.mymodule { 
  requires com.company.myothermodule; 
  requires java.sql; 
}

You can have transitive dependencies (a bit like Maven) thanks to the keyword public.

module java.sql { 
  requires public java.logging; 
}

This means if I have a dependency on the module java.sql, I will have access to all classes included in java.logging (as long as the types are public).

We now have a module dependency graph.

Package visibility

Use of the keyword exports.

module com.company.myothermodule { 
  exports com.company.myothermodule.alpha;  
  exports com.company.myothermodule.beta; 
}

What is exported is visible, by default it’s not!

In Java 9, we have to redefine the keyword public, it comes in different flavours:

• Public to everyone
• Public, but only to specific modules
• Public, only within a module

Public does not mean necessary accessible anymore, that’s a fundamental change.
You can read the Jigsaw specification to know more.

Compilation and execution with module path

Forget about the classpath parameter, there is a new modulepath parameter (or -mp) in the javac / java command line. Its value is one or more directories that contain modules that are required to compile / execute your application.

Also, note there will be default module for the JAR files that are not module-compatible yet (automatic module).