All JDK Release Notes
               JDK 9 Release Notes

JDK 9 Release Notes

Enhancements and Notes


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.




core-libs
 JEP 254 Compact Strings 

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:

  • It is known that the String objects used in jvm/application will be overwhelmingly multi-byte character Strings.
  • In the unexpected event where a severe performance regression is observed in migrating from JDK 8 to JDK 9 and the analysis concludes the Compact String representation is the reason.

 

core-libs/java.lang
 Deprecation Warnings Introduced 

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 forRemoval=true.

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.

The javac command-line options -Xlint:deprecation and -Xlint:removal will enable the respective warning types, and -Xlint:-deprecation 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("deprecation") or @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.

 

core-libs/java.lang
 Unicode 8 support 

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

  • 29 scripts

  • 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 :
    Ahom
    Anatolian Hieroglyphs
    Bassa Vah
    Caucasian Albanian
    Duployan
    Elbasan
    Grantha
    Hatran
    Khojki
    Khudawadi
    Linear A
    Mahajani
    Manichaean
    Mende Kikakui
    Modi
    Mro
    Multani
    Nabataean
    Old Hungarian
    Old North Arabian
    Old Permic
    Pahawh Hmong
    Palmyrene
    Pau Cin Hau
    Psalter Pahlavi
    Siddham
    Sutton SignWriting
    Tirhuta
    Warang Citi

  • 42 new blocks which includes 29 blocks for the new scripts listed above and 13 blocks for the following existing scripts:
    Cherokee Supplement
    CJK Unified Ideographs Extension E
    Combining Diacritical Marks Extended
    Coptic Epact Numbers
    Early Dynastic Cuneiform
    Geometric Shapes Extended
    Latin Extended-E
    Myanmar Extended-B
    Ornamental Dingbats
    Shorthand Format Controls
    Sinhala Archaic Numbers
    Supplemental Arrows-C
    Supplemental Symbols and Pictographs

 

core-libs/java.nio
 Allow use of TransmitFile on Microsoft Windows 

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. 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 -Djdk.nio.enableFastFileTransfer or -Djdk.nio.enableFastFileTransfer=true.

 

core-libs/java.nio
 Ability to limit the capacity of buffers that can be held in the temporary buffer cache 

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.

 

core-libs/java.nio.charsets
 IBM1166 character set now available 

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

 

core-libs/java.util:i18n
 UTF-8 based Properties Files 

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.

 

core-libs/javax.lang.model
 Provided new utility visitors supporting SourceVersion.RELEASE_9 

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.

 

core-svc/tools
 New ManagementAgent.status diagnostic command added. 

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:

Agent: <enabled|disabled>
(
  ConnectionType: <local|remote>
  Protocol: <rmi|...>
  Host: <IP or host name>
  URL: <valid JMX connector URL>
  (
    Properties:
    (
       <propertyname>=<propertyvalue>
    )+
  )?
)+

Where:
  <name> means an arbitrary value
  | means 'or'
  ( and ) denote a block
  + block repeats one or more times
  ? block appears at most once

 

deploy/webstart
 Set 32 or 64 bit JRE requirements in a JNLP file 

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:

<resources arch="x86_64">
     <java version="1.8"/>
</resources>
<resources arch="x86">
     <java version="1.9"/>
</resources>

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.

 

hotspot/runtime
 osset_native_thread_name() cleanups 

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.

 

security-libs
 Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes 

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:

For DSA:
NONEwithDSAinP1363Format
SHA1withDSAinP1363Format
SHA224withDSAinP1363Format
SHA256withDSAinP1363Format

For ECDSA:
NONEwithECDSAinP1363Format
SHA1withECDSAinP1363Format
SHA224withECDSAinP1363Format
SHA256withECDSAinP1363Format
SHA384withECDSAinP1363Format
SHA512withECDSAinP1363Format

 

security-libs/javax.crypto
 Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits 

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.

 

security-libs/javax.security
 Access ExtendedGSSContext.inquireSecContext() result through SASL 

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.

 

security-libs/javax.xml.crypto
 Add security property to configure XML Signature secure validation mode 

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:

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    noDuplicateIds,\
    noRetrievalMethodLoops

Please refer to the definition of the property in the java.security file for more information.

 

security-libs/jdk.security
 New APIs for jar signing 

A new jdk.security.jarsigner.JarSigner API is added to the jdk.jartool module which can be used to sign a JAR file.

 

security-libs/org.ietf.jgss:krb5
 accept yes/no for boolean krb5.conf settings 

Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings.

 

security-libs/org.ietf.jgss:krb5
 Support "include" and "includedir" in krb5.conf 

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.

 

tools/javac
 Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation 

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.

 

tools/jshell
 JShell -- New tool and API for interactive Java 

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.

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

The jshell tool is built on the JShell API, making the evaluation of snippets of Java code available to any Java program.

See:

 

tools/launcher
 Support @-files for java command-line tool 

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

In JDK 9, java now can read arguments from specified files as they are put on the command line. See java command reference and java Command-Line Argument Files for more details.

 

tools/launcher
 Add a new launcher environment variable JDK_JAVA_OPTIONS 

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.

 

xml/javax.xml.xpath
 XPath enhancement 

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.

  1. Support ANY type

javax.xml.xpath supported explicit data types defined by the XPath specification. However, it was missing the important ANY type 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 ANY type so that an XPath evalution can be performed when the return type is unknown.

  1. Improved ease of use

For ease of use, four new evaluateExpression methods are added to the javax.xml.xpath.XPath and javax.xml.xpath.XPathExpression interfaces to allow specifying explicit types as follows:

  • When specified explicitly, the new methods return the specific types, including Boolean, Double, Integer, Long, String and org.w3c.dom.Node.
  • When the return type is expected to be NODESET, the new methods will return a new XPathNodes type. XPathNodes is a new interface that extends Iterable<Node> which makes it easier to use than the traditional org.w3c.dom.NodeList.
  • When the return type is unknown or ANY, the new methods return a new XPathEvaluationResult type. XPathEvaluationResult provides an XPathResultType enum that defines the supported types that are ANY, BOOLEAN, NUMBER, STRING, NODESET, and NODE.

 

xml/jaxp
 A new property "maxXMLNameLimit" is added 

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.

JDK-8086733 (not public)

 

xml/jaxp
 XML Catalog API 

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.