Java 9 will introduce 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 better grasp JavaOne sessions and better prepare you 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 last year at JVM Language Summit on sun.misc.Unsafe
The following critical internal APIs proposed to remain accessible in JDK 9 are:
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
Alan Bateman explains how to use the jdeps and walks you through several examples using a Glassfish jar file, and from Gradle 2.7. He also provides a workaround if you are using a third party application that cannot be updated. Watch his presentation here