Get Ready for Java 9

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! 


Join the discussion

Comments ( 1 )
  • DHEERAJ SUTRAVE Friday, September 16, 2016
    As there are numerous API with current of version of java but the upcoming JDK9 will be having more classes introduced.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.