Java 9 introduces a modular system which is moving away from today’s monolith Java SE platform. Backward compatibility is one of the main priorities and the Oracle engineering team has worked on a smooth transition to Java 9. Nonetheless, there are a number of key changes below that you need to understand. Knowing this information will also help you better prepare for the release of Java 9.
The general compatibility policies indicate that supported APIs can be removed with advanced notice. JEP 277 on enhanced deprecation describes the notification process, the status and intended disposition of APIs, as well as tools to analyze an application’s static usage of deprecated APIs.
JEP 260, about encapsulating most internal APIs, explains that most internal APIs will be inaccessible by default, but leaves a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality.
As a general rule, you should not use unsupported APIs, which are mostly sun.* APIs like sun.misc.Unsafe. Those APIs are meant to be used by Oracle JDK team. Mark Reinhold did an entire talk on sun.misc.Unsafe
The following critical internal APIs proposed to remain accessible in JDK 9 are:
- sun.misc.{Signal,SignalHandler}
- sun.misc.Unsafe (The functionality of many of the methods in this class is now available via variable handles (JEP 193).)
- sun.reflect.Reflection::getCallerClass(int) (The functionality of this method may be provided in a standard form via JEP 259.)
- sun.reflect.ReflectionFactory.newConstructorForSerialization
The above critical internal APIs will be placed in, and their packages exported from, a JDK-specific module named jdk.unsupported. You will find more details on the JEP 260 page.
How do you know whether your program uses or depends on any JDK-internal API? You could identify those APIs from the name of the packages in the source code if you have access to the source code. Sometimes this is a challenge because you might use a third party library that depends on one of those APIs. To identify those APIs, you can use Jdeps, Java dependency analysis tool, which was introduced in JDK 8. You should use the improved version of Jdeps, available in JDK 9 early access releases. There is also a plug-in for Maven.
The jdeps command shows the package-level or class-level dependencies of Java class files. The input class can be a path name to a .class file, a directory, a JAR file, or it can be a fully qualified class name to analyze all class files.
By default, it analyzes all classes specified in the -classpath option and in input files. You will need to use ‘-jdkinternals’ to flag the internal APIs. More information is available on the Jdeps main page. The tool notifies you of the JDK internal APIs to modify as well as suggesting replacements when available. A full list of JDK internal API replacements is available here
More information about module system and JDK 9 can be found online:
JEP 261: Module System
JEP 200: The Modular JDK
JDK 9 release
Release notes
Java 9 expert insights
JDK 9 documentation
Migration guide
Java SE & JDK 9 API Specification
Oracle JDK 9 and JRE 9 Certified System Configurations
Related blog: Modular Development with JDK 9
Two editions of Java Magazine are dedicated to Java 9. Register for free!
Yolande Poirier
Yolande Poirier manages the online experience for the world's biggest IT community. She empowers developers to successfully grow their projects, businesses, and careers. Telling the story of how people use technology, she curates technical content, interviews IT professionals around the world, and write blogs about Java technologies and projects. She is a speaker at international conferences and JavaOne Rock Star, this year's track lead of the developer community day and a long time member of @jduchess, a network of women in Java. She manages @Java, a network of over 350,000 developer enthusiasts.