JDK 9 New Features (original) (raw)

java

JDK 9 Release Notes - New Features

The following items describe additional changes and information about this release. In some cases, the descriptions provide links to additional detailed information about an issue or a change. This page does not duplicate the descriptions provided by the other JDK 9 Release Notes pages and:

You should be aware of the content in those documents as well as the items described on this page.

The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 9. See the JDK 9 Migration Guidefor 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.

New Features

core-libs/java.io:serialization

➜ Serialization Filter Configuration

Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in JEP 290 Serialization Filtering and in /lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled.

core-libs/java.lang

➜ 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

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:

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 if an application does I/O with large multi-megabyte buffers at startup but therefore does I/O with small buffers may see a benefit to using this property. Applications that do I/O using direct buffers will not see any benefit to using this system property.

core-libs/java.nio

➜ Allow use of SIO_LOOPBACK_FAST_PATH on Microsoft Windows

Applications running on server editions of Microsoft Windows that make heavy use of loopback connections may see latency and performance improvements if SIO_LOOPBACK_FAST_PATH is enabled. The system property "jdk.net.useFastTcpLoopback" controls whether the JDK enables SIO_LOOPBACK_FAST_PATH on Microsoft Windows. It is disabled by default but can be enabled by setting the system property on the command line with -Djdk.net.useFastTcpLoopback or -Djdk.net.useFastTcpLoopback=true.

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

➜ RMI Better constraint checking

RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness. RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service. Additional filter patterns can be configured using either a system property or a security property. The "sun.rmi.registry.registryFilter" and "sun.rmi.transport.dgcFilter" property pattern syntax is described in JEP 290 and in /lib/security/java.security.

See JDK-8156802 (not public)

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/java.lang.management

➜ New system property for the remote JMX connector

New JMX agent property - jmxremote.host

A new property, com.sun.management.jmxremote.host, is introduced that specifies the bind address for the default JMX agent. If the latter is not specified, the default JMX agent will listen on all interfaces (0.0.0.0) and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of InetAddress.getLocalHost() method.

core-svc/javax.management

➜ New attribute for JMX RMI JRMP servers specifies a list of class names to use when deserializing server credentials

A new java attribute is defined for the environment to allow a JMX RMI JRMP server to specify a list of class names, these names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a List, then the closure would be constituted by all the concrete classes that should be expected in the serial form of a list of Strings.

By default this attribute is used only by the default agent with { "[Ljava.lang.String;", "java.lang.String" }, so that only arrays of Strings and Strings will be accepted when deserializing the credentials.

The attribute name is: "jmx.remote.rmi.server.credential.types"

Here is an example for a user to start a server with the specified credentials class names: Map<String, Object> env = new HashMap<>(1); env.put("jmx.remote.rmi.server.credential.types", new String[]{ String[].class.getName(), String.class.getName() }); JMXConnectorServer server = JMXConnectorServerFactory.newJMXConnectorServer( url, env, mbeanServer);

the new feature should be used by specifying directly: "jmx.remote.rmi.server.credential.types"

See JDK-8144430 (not public)

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.

deploy/webstart

➜ 32/64-bit interoperability in Java Web Start

The ability to specify a preference to launch a Java Web Start application in 64-bit or 32-bit architectures is now supported, by adding the 'arch' attribute to the JNLP resources block.

hotspot/gc

➜ G1 now collects unreachable Humongous objects during young collections

G1 now tries to collect humongous objects of primitive type (char, integer, long, double) with few or no references from other objects at any young collection. During young collection, G1 checks if any remaining incoming references to these humongous objects are current. G1 will reclaim any humongous object having no remaining incoming references.

Three new experimental JVM options to control this behavior that have been added with this change:

  1. G1EagerReclaimHumongousObjects - This option controls whether G1 makes any attempt to reclaim unreachable humongous objects at every young GC. Default is enabled.
  2. G1EagerReclaimHumongousObjectsWithStaleRefs - When this option is enabled G1 attempts to reclaim humongous objects that may have a few stale incoming references at every young GC. Default is enabled.
  3. G1TraceEagerReclaimHumongousObjects - This option enables printing of some information about the collection of humongous objects at every young GC. Default is disabled.

hotspot/runtime

➜ os::set_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.

hotspot/runtime

➜ New JVM Options: ExitOnOutOfMemoryError and CrashOnOutOfMemoryError

Two new JVM flags have been added:

security-libs/java.security

➜ 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/java.security

➜ Add mechanism to allow non default root CAs to not be subject to algorithm restrictions

'New certpath constraint: jdkCA In the java.security file, an additional constraint named "jdkCA" is added to the jdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression.

Example: To apply this constraint to SHA-1 certificates, include the following: SHA1 jdkCA

security-libs/javax.crypto

➜ Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits

Enhance the JDK security providers to support 3072-bit DiffieHellman and DSA parameters generation, pre-computed DiffieHellman parameters up to 8192 bits and pre-computed DSA parameters up to 3072 bits.

security-libs/javax.net.ssl

➜ Support for Customization of Default Enabled Cipher Suites via System Properties

The system property jdk.tls.client.cipherSuites can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property jdk.tls.server.cipherSuites can be used for customization on the server side.

The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties.

Refer to the Java Cryptography Architecture Standard Algorithm Name Documentation for the standard JSSE cipher suite names, and the Java Cryptography Architecture Oracle Providers Documentation for the cipher suite names supported by the SunJSSE provider.

Note that the actual use of enabled cipher suites is restricted by algorithm constraints.

Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations.

Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk.

security-libs/javax.net.ssl

➜ Support SHA224withDSA and SHA256withDSA in the SunJSSE provider

The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions.

security-libs/javax.net.ssl

➜ TLS Application-Layer Protocol Negotiation Extension

JEP 244 has enhanced the Java Secure Socket Extension (JSSE) to provide support for the TLS Application-Layer Protocol Negotiation (ALPN) Extension (RFC 7301). New methods have been added to the javax.net.ssl classes SSLEngine, SSLSocket, and SSLParameters to allow clients and servers to negotiate an application layer value as part of the TLS handshake.

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/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 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 @deprecated javadoc tag as indicating formal deprecation.

tools/jshell

➜ JShell -- New tool and API for interactive Java

Provide 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, evaluating them and immediately displaying 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 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

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

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.

See JDK-8086733 (not public)