JDK 9 Outreach

Introduction

With JDK 9 development underway in the OpenJDK Community, and based on our experiences with open source projects testing against JDK 9 Early Access builds in the Quality Outreach effort, it seems like a good idea to compile the accumulated wisdom to make it easier for new projects to start testing against JDK 9.

Caveat Lector

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.

The Little Things

Before you get started testing your code against JDK 9, there are a few little things to consider.

JDK 9 Early Access Builds

You can build JDK 9 yourself by following the build instructions to build the OpenJDK source code in the jdk9/jdk9 forest. Please check the list of supported build platforms to verify that your build platform is supported before you attempt building JDK 9 from source yourself.

JDK 9 Early Access builds may also be provided by third parties. Oracle publishes regular JDK 9 builds at http://jdk9.java.net, for example.

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.

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.

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.

JDK 9 changes that may affect your code

Some of the changes targeted for JDK 9 may affect code that relies on deprecated, removed, unsupported, internal or unspecified functionality. The list below has been compiled from the list of JEPs targeted for JDK 9 and other resources. It is not an exhaustive list of changes - there may be other changes you run into that have not been listed here.

Where available, the list provides links to further resources, like JEPs, mailing list threads or JBS issues.

Added

Validate JVM Command-Line Flag Arguments

JEP 245 may affect code that passes invalid flag arguments to the JVM. It validates the arguments to all JVM command-line flags so as to avoid crashes, and ensured that appropriate error messages are displayed when they are invalid.

Changed

Modular Run-Time Images

JEP 220 may affect code that relies on the removed endorsed-standards override mechanism, the removed extension mechanism, and the existence of rt.jar and tools.jar files as well as the old directory layout of files in the JDK & JRE installation image.

New Version-String Scheme

JEP 223 may affect code that relies on the old version string scheme to distinguish major, minor, and security-update releases.

OCSP Stapling for TLS

JEP 249 may affect code connecting to TLS servers that cannot accept the status_request or status_request_v2 TLS extensions. It implements OCSP stapling via the TLS Certificate Status Request extension (section 8 of RFC 6066) and the Multiple Certificate Status Request Extension (RFC 6961). The OCSP stapling feature will be enabled by default in the JDK with this implementation.

Parser API for Nashorn

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

Unified JVM Logging

JEP 158 may change log message formats and possibly the meaning of some JVM options.

Use CLDR Locale Data by Default

JEP 252 may affect code that uses locale-sensitive services such as date, time, and number formatting which may behave differently for locales not supported in JDK 8.

Removed

Remove GC Combinations Deprecated in JDK 8

JEP 214 may affect code that relies on the removed GC combinations.

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 text.

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 the JVM TI hprof Agent

JEP 240 may affect code that relies on the removed hprof agent library as part of the JDK.

Remove the jhat Tool

JEP 241 may affect code that relies on the removed experimental, unsupported, and out-of-date jhat tool.

Removed API references to java.awt.peer and java.awt.dnd.peer packages

JDK-8037739 may affect code that uses types from java.awt.peer and java.awt.dnd.peer packages.

All methods that refer to types defined in the java.awt.peer and java.awt.dnd.peer packages (the "peer types") will be removed from the Java API in Java SE 9. Application code which calls any such method which accepts or returns a type defined in these packages will no longer link. This is a BINARY incompatible change.

Removed Packer/Unpacker addPropertyChangeListener and removePropertyChangeListener methods

JDK-8029806 may affect code that uses the Packer/Unpacker addPropertyChangeListener and removePropertyChangeListener methods, which were deprecated in JDK 8, and removed in JDK 9.

Removed LogManager addPropertyChangeListener and removePropertyChangeListener methods

JDK-8029805 may affect code that uses the LogManager addPropertyChangeListener and removePropertyChangeListener methods, which were deprecated in JDK 8, and removed in JDK 9.

Removed com.sun.security.auth.callback.DialogCallbackHandler  

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.

Removed support for 1.5 and earlier source and target options

JDK-8011044 may affect source code that uses javac -source or -target options below 6/1.6 to compile.

Build

Milling Project Coin

JEP 213 may affect source code that uses underscore ("_") as an identifier. Its use generated a warning as of Java SE 8, and has been turned into an error in JDK 9.

Simplified Doclet API

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.

Annotations Pipeline 2.0

JEP 217 may affect source code that uses annotations due to the refactoring of the javac annotation pipeline, which should not be externally noticeable except where bugs were fixed and correctness improved.

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.

Feedback on new JDK 9 features

Make G1 the Default Garbage Collector

As described in JEP 248, switching to a low-pause collector in JDK 9 such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which is currently the default. A call for feedback and data points regarding this change went out on the hotspot-dev mailing list, where such input should be provided.

jshell: The Java Shell (Read-Eval-Print Loop)

As described in JEP 222, Project Kulla introduces a new REPL for JDK 9.  You can test it by following the instructions from the latest Adoption Group hackday. Feedback on this feature should be provided on the kulla-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.