JavaOne 2015: Prepare For JDK 9 // nipafx

JavaOne 2015 saw a series of talks by the Project Jigsaw team about modularity in Java 9. They are all very interesting and full of valuable information and I urge every Java developer to watch them.

Beyond that I want to give the community a way to search and reference them, so I summarize them here:

I made an effort to link to as many external resources as possible to keep the individual posts short. The play icons will take you straight to the corresponding point in the ten hour long video streams that Oracle put online for each room and day. (Great format, folks!) Not only did they (so far) fumble the cutting, they also seem to have resorted to low-volume mono sound so make sure to crank up the volume.

Let's start with preparations for JDK 9!

Content: What to expect when moving from JDK 8 to JDK 9
Speaker: Alan Bateman
Links: Video and Slides

Always embed videos

(and give me a cookie to remember - privacy policy)

Watch on YouTube

▚Background

Alan Bateman begins the talk by giving some background information.

▚JDK 9 And Project Jigsaw Goals

A quick recap of Jigsaw's goals. For more details, see my post about them.

▚Modularity Landscape

A short overview over the multitude of Java Specification Requests (JSRs) and JDK Enhancement Proposals (JEPs) that cover Project Jigsaw's efforts.

▚Compatibility

Bateman categorizes the kinds of APIs exposed by the JDK:

Supported and intended for external use:
- JCP standard: java.*, javax.*
- JDK-specific API: some com.sun.*, some jdk.*
Not intended for external use: sun.*, rest com.sun.*, rest jdk.*

He points out that if an application uses only supported APIs and works on Java N, it should also work on Java N+1. Java 9 will make use of this and change/remove APIs that have been internal or deprecated in Java 8.

He then goes into managing (in)compatibilities and mentions a post by Joseph Darcy, Kinds of Compatibility: Source, Binary, and Behavioral, that he recommends to read. It sheds some light on the different aspects of compatibility and hence, by extension, the complexity of evolving Java.

▚Incompatible Changes In JDK 9

The bulk of this talk covers the different incompatibilities Java 9 will incur. This is largely covered by my post about how Java 9 may break your code.

▚Encapsulating JDK-Internal APIs

Bateman starts by presenting some data on uses of internal APIs. Details can be found on slide 16 but the gist is that only a couple of APIs are frequently used.

APIs that are not used in the wild or are only used for convenience are non-critical. By default, these will be encapsulated in Java 9. Those in actual use for which it would be hard or impossible to create implementations outside of the JDK are deemed critical. If alternatives exist, they will also be encapsulated.

The critical APIs without alternative will be deprecated in Java 9, with the plan to remove them in 10. JEP 260 proposes the following APIs for this:

sun.misc.Unsafe
sun.misc.{Signal,SignalHandler}
sun.misc.Cleaner
sun.reflect.Reflection::getCallerClass
sun.reflect.ReflectionFactory

If you miss something on the list, contact the Jigsaw team and argue your case (and bring data to support it).

He then goes into how jdeps can be used to find the uses of internal APIs. This part also contains some examples of what will happen if problematic code is run on JDK 9 (start here) and how to solve such issues (start here).

▚Removing API

This is quick. The following six methods will not be present in Java 9:

java.util.logging.LogManager::addPropertyChangeListener
java.util.logging.LogManager::removePropertyChangeListener
java.util.jar.Pack200.Packer::addPropertyChangeListener
java.util.jar.Pack200.Packer::removePropertyChangeListener
java.util.jar.Pack200.Unpacker::addPropertyChangeListener
java.util.jar.Pack200.Unpacker::removePropertyChangeListener

▚Change Of JDK/JRE Binary Structure

By merging JDK and JRE into a common structure, several existing practices will stop working.

Bateman describes some of the problems with the old run-time image directory layout and presents how the new one will look. Slides 29 and 30 juxtapose both layouts:

Since Java 7 there is an API with which tools can interact with these files regardless of the physical layout. This also means that version N can access version N+1 files.

▚Removed Mechanisms

As I described earlier, the endorsed standards override mechanism and the extension mechanism will be removed. They will be replaced by upgradeable modules.

▚Other Changes

See JEP 261 (section Risks And Assumptions) for a full list of changes. Bateman names a few:

Application and extension class loaders are no longer instances of java.net.URLClassLoader.
Command line arguments -Xbootclasspath and -Xbootclasspath/p are removed.
System property sun.boot.class.path is removed.

▚Non-Jigsaw Incompatibilities in Java 9

Bateman also shorty addresses two issues that are not connected to Project Jigsaw but will show up in Java 9 and might break some code:

The version-string schema changes.

For details see JEP 223 - it also has a nice comparison of current and future version strings.

Underscore is no longer allowed as a one-character identifier.

▚What Can You Do To Prepare For Java 9?

There are a couple of preparatory steps you can take:

Check code for usages of JDK-internal APIs with jdeps.
Check code that might be sensitive to the version-string schema change.
Check code for uses of underscore as an identifier.
If you develop tools, check code for a dependency on rt.jar, tools.jar, or the runtime-image layout in general.
Test the JDK 9 EA builds and Project Jigsaw EA builds.

Make sure to report any unexpected or overly problematic findings back to the Jigsaw mailing list.

▚Questions

There were a couple of question, of which I picked the two most interesting ones.

▚How Can Libraries Target Java 8 and Java 9?

JEP 238 will introduce multi-release JARs, i.e. JARs that can contain specialized code for specific Java releases.

▚When Does Support For Java 8 End?

Nobody on stage knew the exact answer so they pointed to the documentation of Oracle's update policy on oracle.com. The current answer is: Not before September 2017.