Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
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:
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:
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:
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
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:
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 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
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.
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".
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.
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.
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
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.
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.
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:
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.
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.
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.
jdk.security.jarsigner.JarSigner API is added to the
jdk.jartool module which can be used to sign a JAR file.
accept yes/no for boolean krb5.conf settings
Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings.
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.
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.
Support @-files for java command-line tool
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.
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.
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.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.
For ease of use, four new
evaluateExpression methods are added to the
javax.xml.xpath.XPathExpression interfaces to allow specifying explicit types as follows:
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
ANY, the new methods return a new
XPathResultTypeenum that defines the supported types that are
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 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.