Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

JDK 9 has not been released yet. That means the tips and suggestions accumulated here should not be taken as the final word on how to adjust your code for JDK 9 as some things may (and probably will) change as the set of JEPs targeted for JDK 9 changes. If in doubt, ask - preferably on the adoption-discuss mailing list.

JDK 9 Features

This page does not provide a comprehensive list of planned or targeted JDK 9 features. For an up to date list of JEPs targeted for JDK 9, please consult the JDK 9 Project page.

...

JDK 9 Early Access builds may also be provided by third parties. Oracle publishes regular JDK 9 builds at http://jdk9jdk.java.net/9, for example. In the same location, Oracle also publishes regular JDK 9 builds based on the latest Project Jigsaw source code at http://jdk.java.net/jigsaw/.

Look for unrecognized VM options

If your application's startup script launches the JDK 9 JVM with an unrecognized VM option, it will exit and let you know that it couldn't create a VM because of that unrecognized VM option. Some of the VM flags that were deprecated in JDK 8, have been removed in JDK 9 - like those relating to the permanent generation, which was removed in JDK 8.

For example, if your application's startup script attempts to launch the JDK 9 JVM providing an unrecognized -XX:MaxPermSize=256m option, the JDK 9 JVM will exit with an error message:

Unrecognized VM option 'MaxPermSize=256m'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Removing the unrecognized VM option from its startup script would allow the application to proceed.

Run jdeps on your code

In JDK 8 a new Java Dependency Analysis Tool (jdeps) was added to help developers understand the static dependencies of their applications and libraries. It can help you find dependencies on any internal, unsupported or private APIs that your application or its libraries use. A program using such APIs is not guaranteed to work in future versions of JDK 9 or even the same platform. For more information, please see this document.

A jdeps plugin for Apache Maven exists.

For best results, please make sure to run jdeps from the most recent JDK 8 update release or JDK 9 Early Access build.

Update your dependencies

Third-party libraries that encounter issues on JDK 9 may have had those issues fixed meanwhile as their developers begun to test with JDK 9 and address problems found. If you encounter issues with third party libraries, please check if there is a newer version that addresses them, and update your code to depend on the newer version.

For example, if your application uses Eclipse RCP 4.4 or below, it may exit with an error message on JDK 9:

       java.lang.NoClassDefFoundError: org/w3c/dom/stylesheets/StyleSheet

.

Run jdeps on your code

In JDK 8 a new Java Dependency Analysis Tool (jdeps) was added to help developers understand the static dependencies of their applications and libraries. It can help you find dependencies on any internal, unsupported or private APIs that your application or its libraries use. A program using such APIs is not guaranteed to work in future versions of JDK 9 or even the same platform. For more information, please see this document.

A jdeps plugin for Apache Maven exists.

For best results, please make sure to run jdeps from the most recent JDK 8 update release or JDK 9 Early Access build.

Update your dependencies

Third-party libraries that encounter issues on JDK 9 may have had those issues fixed meanwhile as their developers begun to test with JDK 9 and address problems found. If you encounter issues with third party libraries, please check if there is a newer version that addresses them, and update your code to depend on the newer version.

For example, if your application uses Eclipse RCP 4.4 or below, it may exit with an error message on JDK 9:

       java.lang.NoClassDefFoundError: org/w3c/dom/stylesheets/StyleSheet

Eclipse RCP 4.5 contains a fix for that issue.

Cross compilation for older platform versions

In order to use javac to cross-compile to an older release of the platform it is not sufficient to just set the -source and -target options to the older value; the bootclasspath must also be set to correspond to the older release too. Setting the bootclasspath is sometimes forgotten, potentially leading to obscure errors at runtime.

In JDK 9, the new -release flag in javac addresses both of these shortcomings. Now only a single flag (-release) needs to be set to cross compile compared to three flags (-source, -target, -bootclasspath) and the needed information is included in the JDKEclipse RCP 4.5 contains a fix for that issue.

Testing Your Code

In general, it's simpler to start by building your code in your familiar build environment, and test it by running it on JDK 9, than to start by building it on JDK 9. The tools and libraries used in your build process might themselves not yet have been tested with JDK 9 by their developers.

...

JEP 236 may affect code that uses internal classes in the jdk.nashorn.internal.ir package and its sub-packagesin the jdk.nashorn.internal.ir package and its sub-packages.

Prepare for v53 class files

JDK-8148651 may affect code that needs to process class files. Anyone writing tools and libraries for use on JDK 9 that process class files should update their code to handle the new version number. Code using such tools and libraries should be updated to a version that supports v53 class files.

Prepare JavaFX UI Controls & CSS APIs for Modularization

...

JEP 229 may affect code that uses keystores. It changes the default keystore type from JKS to PKCS12. By default, new keystores will be created in the PKCS12 keystore format. Existing keystores will not change and keystore applications can continue to explicitly specify the keystore type they require. the keystore type they require. 

Disable SHA-1 Certificates

JEP 288 may affect code that uses X.509 certificate chains with SHA-1 based signatures.

Enable GTK 3 on Linux

JEP 283 may affect graphical applications on Linux. In cases where GTK 3 is required for interoperability, and this requirement can be detected sufficiently early, GTK 3 will be enabled automatically. 

Encapsulate Most Internal APIs

...

JEP 226 may affect code that loads property files. It defines a means for applications to specify property files encoded in UTF-8, and extends the ResourceBundle API to load them by default.

Removed

Remove apple script engine code in jdk repository

JDK-8143404 may affect code that relies on the removed AppleScript engine.

Remove GC Combinations Deprecated in JDK 8

...

Users who are using any of the flags that are being removed will have to update their JVM-startup command lines. If they are moving from JDK 8 to JDK 9 then they will already have seen warning messages and thus should not be surprised. For a detailed list of the flags and flag combinations that have stopped working in JDK 9, please consult the JEP textthe JEP text.

Remove HTTP Proxy implementation from RMI

JDK-8066750 may affect code that relies on the removed HTTP Proxy implementation in RMI.

Remove Launch-Time JRE Version Selection

JEP 231 may affect code that relies on the removed ability to request, at JRE launch time, a version of the JRE that is not the JRE being launched.

Remove java-rmi.exe and java-rmi.cgi

JDK-6512052 may affect code that relies on the removed java-rmi.exe launcher.

Remove the JVM TI hprof Agent

...

JDK-8029904 may affect code that uses the com.sun.security.auth.callback.DialogCallbackHandler, which was deprecated in JDK 8, and removed in JDK 9.callback.DialogCallbackHandler, which was deprecated in JDK 8, and removed in JDK 9.

Remove stopThread RuntimePermission from the default java.policy

JDK-7067728 may affect code that relies on the removed stopThread RuntimePermission from the default java.policy.

Remove support for serialized applets from java.desktop

JDK-8134808 may affect code that relies on support for serialized applets.

Build

Annotations Pipeline 2.0

...

JEP 217 may affect source code that uses the applet API. The deprecation annotations will cause deprecation warnings to be emitted by the Java compiler for all compiler for all code that uses this API. If warnings are treated as errors, they will result in build failure.

Enhanced Deprecation

JEP 277 may affect source code that uses this API. If warnings are treated as errors, they will result in build failurea deprecated Java SE API. Several Java SE APIs will have a @Deprecated annotation added, updated, or removed. Deprecating APIs will increase the number of mandatory warnings that projects encounter when building against newer versions of Java SE. For more information about these planned changes, please consult the JEP text.

HTML5 Javadoc

JEP 224 may affect source code with Javadoc comments since the -Xdoclint feature of javadoc will be modified to validate input comments based upon the requested markup.

...

JEP 221 may affect code that uses the Doclet API. It replaces the Doclet API with a simpler design that leverages newer alternative APIs with improved functionality, and updates the standard doclet to use it.

...

functionality, and updates the standard doclet to use it.

Feedback on new JDK 9 features

If you would like to provide feedback on JDK 9, but don't know yet where to start, please begin by subscribing to the adoption-discuss mailing list, and initiating a conversation on that mailing list about your particular item of feedback. Depending on the content, you may be asked to file an issue in in JBS, to provide further information or to continue the conversation on a specific OpenJDK Community mailing list more suitable for further discussion.

Initial module-system design, API, and early-access builds

JEP 261 implements the Java Platform Module System, as specified by JSR 376, together with related JDK-specific changes and enhancements. As announced on the jigsaw-dev mailing list, experience reports from early testers and adopters are especially welcome. Please try out the EA builds and let the developers know what you learn on the jigsaw-dev mailing list.

Public API for internal Swing classes

According to the JEP 200: The Modular JDK we expect that classes from internal packages (like sun.swing) will not be accessible. If you are using the internal Swing API and it is not possible to replace it by public API, please provide feedback on the swinglist, experience reports from early testers and adopters are especially welcome. Please try out the EA builds and let the developers know what you learn on the jigsaw-dev mailing list.

Other potential changes to consider

There may be other changes worth considering to add to this page. If you have suggestions for items to add to this list, please send an e-mail to the adoption-discuss mailing list.