The following items describe some of the enhancements in Java SE 9 and JDK 9. The descriptions in these release note items often include links to documentation that describes the enhancement in greater detail. Other sources of information about important enhancements and new features in Java SE 9 and JDK 9 include:
What’s New in JDK 9 - Identifies the APIs, features, and options that were removed in Java SE 9 and JDK 9 as well as provides links to the documents where they are described in detail.
JSR 379: Java SE 9: Annex 1 - Documents the changes to the specification made between Java SE 8 and Java SE 9. This document includes descriptions of those new features and enhancements that are also changes to the specification.
You should be aware of the content in those documents as well as the items described in this release notes page.
The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 9. See the JDK 9 Migration Guide for descriptions of specific compatibility issues.
The Kinds of Compatibility page on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:
Source: Source compatibility concerns translating Java source code into class files.
Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link without error.
Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.
See the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for more information about compatibility as it relates to JDK 9.
In JDK 9 the internal character storage of the java.lang.String, StringBuilder, and StringBuffer classes has been changed from a UTF-16 char array to a byte array plus a one-byte encoding-flag field. The new storage representation stores/encodes the characters either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string. The newly added encoding flag field indicates which encoding is used. This feature reduces, by 50%, the amount of space required for String objects to store the characters if the String object only contains single-byte/ latin-1 characters.
A new jvm option -XX:-CompactStrings has been introduced in JDK 9 to disable this feature, which might be worth considering when:
Several APIs have been deprecated in Java SE 9. This will cause
javac to emit a variety of warnings during compilation. A deprecation warning will be emitted at the use site of an API deprecated with
forRemoval=false. A removal warning will be emitted at the use site of an API deprecated with
A deprecation or removal warning is a recommendation that code be migrated away from the deprecated API. A removal warning is particularly strenuous, as it is an indication that the deprecated API will generally be removed from the next major release of the platform. However, it is not always practical to migrate code immediately. Therefore, two mechanisms have been provided for controlling the warnings that are emitted by
javac: command-line options and annotations in source code.
javac command-line options
-Xlint:removal will enable the respective warning types, and
-Xlint:-removal will disable the respective warning types. Note that removal warnings are enabled by default.
The other mechanism is to add the
@SuppressWarnings("removal") annotation to the source code. This annotation can be added at the declaration of a module, class, method, field, or local variable to suppress the respective warning types emitted within that declaration.
For further information about deprecation, see JEP 277 and the documentation for the
java.lang.Deprecated annotation type.
The JDK 9 release includes support for Unicode 8.0. Since the release of JDK 8, which supported Unicode 6.2.0, the Unicode 8.0 introduced the following new features that are now included in JDK 9:
10,555 new characters
42 new blocks
10,555 new characters; Includes the Georgian Lari currency symbol and two newly adopted currency symbols:
Manat, used in Azerbaijan
Ruble, used in Russia and other countries.
29 new scripts :
Old North Arabian
Pau Cin Hau
42 new blocks which includes 29 blocks for the new scripts listed above and 13 blocks for the following existing scripts:
CJK Unified Ideographs Extension E
Combining Diacritical Marks Extended
Coptic Epact Numbers
Early Dynastic Cuneiform
Geometric Shapes Extended
Shorthand Format Controls
Sinhala Archaic Numbers
Supplemental Symbols and Pictographs
Applications running on server editions of Microsoft Windows that make heavy use of
java.nio.channels.FileChannel.transferTo may see performance improvements if the implementation uses
TransmitFile makes use of the Windows cache manager to provide high-performance file data transfer over sockets. The system property "
jdk.nio.enableFastFileTransfer" controls whether the JDK uses
TransmitFile on Microsoft Windows. It is disabled by default but can be enabled by setting the system property on the command line with
The system property
jdk.nio.maxCachedBufferSize has been introduced in JDK 9 to limit the memory used by the "temporary buffer cache". The temporary buffer cache is a per-thread cache of direct memory used by the NIO implementation to support applications that do I/O with buffers backed by arrays in the Java heap. The value of the property is the maximum capacity of a direct buffer that can be cached. If the property is not set, then no limit is put on the size of buffers that are cached. Applications with certain patterns of I/O usage may benefit from using this property. In particular, an application may see a benefit to using this property if it does I/O with large multi-megabyte buffers at startup but thereafter does I/O with small buffers. Applications that do I/O using direct buffers will not see any benefit to using this system property.
This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include "cp1166","ibm1166", "ibm-1166", "1166".
Properties files in UTF-8 encoding are now supported by ResourceBundle, with automatic fall back to ISO-8859-1 encoding if needed. For more detail, refer to PropertiyResourceBundle class description.
The constructors for the utility visitors in javax.lang.model.util that correspond to the RELEASE_6 source level have been deprecated since the reference implementation regards -source 6 as obsolete. Authors of annotation processors should update their processors to support newer source versions.
A new ManagementAgent.status diagnostic command is introduced for querying the JMX agent's status.
The status will be relayed to the user in the following form:
Host: <IP or host name>
URL: <valid JMX connector URL>
<name> means an arbitrary value
| means 'or'
( and ) denote a block
+ block repeats one or more times
? block appears at most once
Web Start applications can now specify requested JREs with their arch attributes, and select the first one available that matches, even if it is not the same arch (32 bit vs 64 bit) as the currently running JRE. For example, the JNLP content below would place first preference on 64 bit JDK8, and if not available, 32 bit JDK9:
Note that in the above example, in order to launch a 64 bit 1.8 JRE, a 64 bit 9 JRE must be installed. If only a 32 bit 9 JRE is installed, the 64 bit 1.8 JRE is unavailable.
On platforms that support the concept of a thread name on their native threads, the
java.lang.Thread.setName() method will also set that native thread name. However, this will only occur when called by the current thread, and only for threads started through the
java.lang.Thread class (not for native threads that have attached via JNI). The presence of a native thread name can be useful for debugging and monitoring purposes. Some platforms may limit the native thread name to a length much shorter than that used by the
java.lang.Thread, which may result in some threads having the same native name.
A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method:
Extend to support 3072-bits DH and DSA parameters generation, and pre-computed DH parameters up to 8192 bits and pre-computed DSA parameters up to 3072-bits.
The output of
ExtendedGSSContext.inquireSecContext() is now available as negotiated properties for the SASL GSSAPI mechanism using the name "com.sun.security.jgss.inquiretype.<type_name>", where "type_name" is the string form of the
InquireType enum parameter in lower case. For example, "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the session key of an established Kerberos 5 security context.
A new security property named
jdk.xml.dsig.secureValidationPolicy has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the
java.security configuration file is:
disallowReferenceUriSchemes file http https,\
Please refer to the definition of the property in the
java.security file for more information.
jdk.security.jarsigner.JarSigner API is added to the
jdk.jartool module which can be used to sign a JAR file.
Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings.
The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed.
Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors.
If the javadoc deprecated tag is used on an element without it also being deprecated by using the @Deprecated annotation, the compiler will by default produce a new warning to this effect.
The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible).
In a future version of Java SE, the compiler may no longer treat the @deprecated javadoc tag as indicating formal deprecation.
Provides an interactive tool to evaluate declarations, statements, and expressions of the Java programming language, together with an API so that other applications can leverage this functionality. Adds Read-Eval-Print Loop (REPL) functionality for Java.
jshell tool accepts "snippets" of Java code, evaluates them and immediately displays the results. Snippets include variable and method declarations without enclosing class. An expression snippet immediately shows its value. The
jshell tool also accepts commands for displaying and controlling snippets.
jshell tool is built on the JShell API, making the evaluation of snippets of Java code available to any Java program.
java launcher now supports reading arguments from "argument files" specified on the command line. It is not uncommon that the
java launcher is invoked with very long command lines (a long class path for example). Many operating systems impose a limit on the length of a command line, something that "argument files" can be used to work around.
JDK 9 supports a new environment variable
JDK_JAVA_OPTIONS to prepend options to those specified on the command line. The new environment variable has several advantages over the legacy/unsupported
_JAVA_OPTIONS environment variable including the ability to include
java launcher options and
@file support. The new environment variable may also be useful when migrating from JDK 8 to JDK 9 for cases where new command line options (that are not supported by JDK 8) are needed.
For more details, see java launcher reference guide.
Java SE 9 improves the
javax.xml.xpath API with new APIs that make use of modern language features to facilitate ease of use and extend support of the XPath specification.
javax.xml.xpathsupported explicit data types defined by the XPath specification. However, it was missing the important
ANYtype without which the XPath API assumes that an explicit type is always known, which is not true in some circumstances. The new API now supports the
ANYtype so that an XPath evalution can be performed when the return type is unknown.
For ease of use, four new
evaluateExpressionmethods are added to the
javax.xml.xpath.XPathExpressioninterfaces to allow specifying explicit types as follows:
- When specified explicitly, the new methods return the specific types, including
- When the return type is expected to be
NODESET, the new methods will return a new
XPathNodesis a new interface that extends
Iterable<Node>which makes it easier to use than the traditional
- When the return type is unknown or
ANY, the new methods return a new
XPathResultTypeenum that defines the supported types that are
A new property "maxXMLNameLimit" is added to limit the maximum size of XML names, including element name, attribute name and namespace prefix and URI. It is recommended that users set the limit to the smallest possible number so that malformed XML files can be caught quickly. For more about XML processing limits, please see The Java Tutorials, Processing Limits.
Java SE 9 introduces a standard XML Catalog API that supports the OASIS XML Catalogs version 1.1 standard. The API defines catalog and catalog-resolver abstractions that can be used as an intrinsic or external resolver with the JAXP processors that accept resolvers.
Existing libraries or applications that use the internal catalog API shall consider migrating to the new API in order to take advantage of the new features.