JDK 9 Release Notes

• All JDK Release Notes
• JDK 9 Release Notes

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

See JDK-8054307

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.

See JDK-8065614

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

See JDK-8072600

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.

See JDK-8064407

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.

See JDK-8147468

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

See JDK-8071447

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.

See JDK-8027607

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.

See JDK-8050430

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

See JDK-8023093

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.

See JDK-8055448

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.

See JDK-7102541

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

See JDK-8042967

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.

See JDK-8072452

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.

See JDK-8044085

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

See JDK-8151893

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.

See JDK-8056174

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.

See JDK-8029995

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.

See JDK-8029994

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.

See JDK-8164073

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:

• jshell tool User's Guide
• jshell tool Reference

See JDK-8043364

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.

See JDK-8027634

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.

See JDK-8170832

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.

See JDK-8054196

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.

See JDK-8081248