JDK 11 Early-Access Release Notes

Last Updated: 2018/05/25

The following is a draft of the Release Notes that will be shipped with JDK 11. Until this version releases the contents are subject to change.

Since build 15  Integrations

 Kerberos sequence number issues

Previously, when mutual auth was not requested by the Kerberos 5 initiator, there was no mechanism to negotiate the acceptor's initial sequence number. With this release, if the system property "sun.security.krb5.acceptor.sequence.number.nonmutual" is set to "initiator", the SunJGSS provider will use the initiator's initial sequence number as the acceptor's initial sequence number. If set to "zero" or "0", 0 is used. The default value is "initiator". All other values are illegal and will throw an Error when the system property is read.

See JDK-8201627

Since build 13  Integrations

 Removal of appletviewer launcher

The appletviewer tool was deprecated in JDK 9 (see JDK-8074165) and has been removed in this release.

See JDK-8200146
 java.lang.ref.Reference does not support cloning

java.lang.ref.Reference::clone method always throws CloneNotSupportedException. Reference objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a Reference object with the same referent and reference queue instead.

See JDK-8201793

Since build 11  Integrations

 SelectableChannel.register may be invoked while a selection operation is in progress

java.nio.channels.Selector historically specified its key set (the set containing the keys representing the channels registered with the selector) to not be thread safe. Selection operations were specified to synchronize on this key set. Additionally, the register methods defined by java.nio.channels.SelectableChannel (SocketChannel, ServerSocketChannel, ...) were also specified to synchronize on the selector's key set and therefore block if invoked concurrently with another registration or selection operation.

The specification has changed in Java SE 11 so that the selector's key set is specified to be safe for use by concurrent threads. Selection operations are no longer specified to synchronize on the key set. This allows threads to register channels while a selection operation is in progress; the new registration takes effect at the next selection operation. SelectionKey interestOps(int) has also been re-specified so that it can be called at any time. If invoked while a selection operation is in progress then it has no effect upon that operation; the change to the key's interest set will be seen by the next selection operation.

Code that synchronizes on the Selector's selected-key set is not impacted by this change as selection operations continue to be specified to synchronize on the selected-key set.

The Selector API is pluggable. SelectorProvider implementations that exist outside of the JDK will need to be updated to align their Selector implementation with the updated specification.

See JDK-8201315
 Lazy allocation of compiler threads

In tiered compilation mode (which is on by default) the VM starts a large number of compiler threads on systems with many CPUs regardless of available memory and number of compilation requests. This leads to inefficient use of resources; they consume memory even if they are idle, almost all of the time.

To address that the implementation was changed to start only one compiler thread of each type during startup, and handle the start and shutdown of further threads dynamically. It is controlled by a new command line flag which is on by default:


See JDK-8198756

Since build 10  Integrations

 Removal of "com.sun.awt.AWTUtilities" class

The "com.sun.awt.AWTUtilities" class was deprecated forRemoval=true in JDK 10 (JDK-8187253). This class is unused in the JDK and have been removed in this release.

See JDK-8200149
 Enhanced KeyStore Mechanisms

A new security property named jceks.key.serialFilter has been introduced. If this filter is configured, the JCEKS KeyStore uses it during the deserialization of the encrypted Key object stored inside a SecretKeyEntry. If it is not configured or if the filter result is UNDECIDED (for example, none of the patterns match), then the filter configured by jdk.serialFilter is consulted.

If the system property jceks.key.serialFilter is also supplied, it supersedes the security property value defined here.

The filter pattern uses the same format as jdk.serialFilter. The default pattern allows java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type, and javax.crypto.spec.SecretKeySpec but rejects all the others.

Customers storing a SecretKey that does not serialize to the above types must modify the filter to make the key extractable.

JDK-8189997 (not public)
 3DES Cipher Suites Disabled

To improve the strength of SSL/TLS connections, 3DES cipher suites have been disabled in SSL/TLS connections in the JDK via the jdk.tls.disabledAlgorithms Security Property.

JDK-8175075 (not public)

Since build 9  Integrations

 Remove SNMP support

jdk.snmp module has been removed.

With jdk.snmp module removed, the following com.sun.management.snmp.* properties will become noop when setting via the -D option or via the management.properties configuration.

See JDK-8071367
 KerberosString uses UTF-8 encoding by default

The KerberosString ASN.1 type now uses the UTF-8 encoding by default. A KerberosString can be used to encode principal names, realm names, and other text-based fields. Set the system property "sun.security.krb5.msinterop.kstring" to "false" to encode KerberosString as ASCII.

See JDK-8200152
 Readiness information previously recorded in SelectionKey ready set not preserved

The java.nio.channels.Selector API specifies precisely how selection operations add selection keys to the selector's selected-key set or update the readiness information of selection keys already in the set. The Selector implementations in the JDK did not historically implement the latter correctly, meaning that the readiness information was overridden and previous readiness information was not preserved for cases where a channel is selected and its key is already in the selected-key set. This issue has been fixed in JDK 11. This behavior change may surprise code that invokes select (or selectNow) and doesn't process keys added to the selected-key set before performing another selection operation.

See JDK-8200458

Since build 7  Integrations

 GTK3 is now the default on Linux/Unix.

Newer versions of Linux, Solaris, and other Unix flavor desktop environments use GTK3, whilst still supporting GTK2

Previously JDK would default to loading the older GTK2 libraries. In this release it defaults to loading GTK3 libraries. Loading is typically triggered by using the Swing GTK Look And Feel.

If for any reason this causes issues for an application, the old behavior can be restored by using a system property: -Djdk.gtk.version=2.2

See JDK-8198649
 DatagramChannel.send throws AlreadyConnectedException instead of IllegalArgumentException

Prior to JDK 11, invoking DatagramChannel.send(ByteBuffer,SocketAddress) on a DatagramChannel connected to an address different from the address specified to the method caused an unspecified IllegalArgumentException to be thrown. The specification has been clarified in Java SE 11 to specify java.nio.channels.AlreadyConnectedException for this case and the implementation changed to throw the correct exception.

See JDK-8198753
 Garbage collectors adaptively scale the number of threads by default

The number of threads garbage collectors use in the garbage collection stop-the-world pauses determine the number of threads to use based on the maximum size of the Java heap. The flag -XX:UseDynamicNumberOfGCThreads is now true (enabled) by default.

This improves startup time and reduces resource usage particularly for Java applications run with a small Java heap.

If you experience performance reductions particularly on applications that use a small amount of Java heap, you can disable this new behavior by specifying -XX:- UseDynamicNumberOfGCThreads on the command line.

See JDK-8198510
 Deprecate -XX+AggressiveOpts

The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and will be removed in a future release. The option was originally supposed to enable some experimental optimizations of the C2 compiler to improve performance of specific benchmarks. Most features have been removed or integrated over time leaving the behavior of the option ill-defined and error-prone. The only effect that the flag currently has is setting "AutoBoxCacheMax" to 20000 and "BiasedLockingStartupDelay" to 500. The same configuration can be achieved by setting the corresponding flags via the command line. Therefore "-XX:+AggressiveOpts" will no longer be available in a future release.

See JDK-8199777
 New PerfCounters for STW phases on Concurrent GC are available

A new GC performance counter for pauses during the concurrent phase has been added. This counter will be listed by jstat under the CGC (concurrent GC) heading. This information is only available for for GCs with a concurrent phase and what's included is GC specific:

For CMS these pauses were previously included in the time listed by jstat under the FGC (full GC) heading.

The information is also available via the jcmd using PerfCounter.print.

See JDK-8153333

Since build 6  Integrations

 remove terminally deprecated sun.misc.Unsafe.defineClass

In JDK 11 sun.misc.Unsafe.defineClass has been removed. Users should use the public replacement java.lang.invoke.MethodHandles.Lookup.defineClass which was added in Java SE 9. For more details see the Java documentation:


See JDK-8193033

Since build 4  Integrations

 javax.transaction.xa package moved to the java.transaction.xa module

The maintenance JSR for the Java Transaction (JSR 907) has dropped package javax.transaction.xa from the API to allow it be subsumed by Java SE.

As part of this effort, package javax.transaction.xa moves from module java.sql to a new module java.transaction.xa.

The following types continue to be part of the javax.transaction.xa package:

The change should be transparent to existing applications on the class path or module path.

See JDK-8197533
 Missing types consistently modeled as ERROR types

Annotation processors and other javax.lang.model clients could have in some cases observe missing types to be modelled as DECLARED types and a javac internal exception, CompletionFailure, to be thrown out of the model methods when manipulating such types. That is no longer the case, missing types are consistently modelled as ERROR types, and the javac internal CompletionFailures is not throw out to the API clients.

See JDK-8187950

Since build 3  Integrations

 (ch) Separate blocking and non-blocking code paths

The implementations of SocketChannel, ServerSocketChannel, DatagramChannel, Pipe.SourceChannel and Pipe.SinkChannel have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes:

  1. Invoking configureBlocking(false) on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed.

  2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel.

  3. Closing a connected SocketChannel that is registered with a Selector will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. The behavior varied by platform in pervious releases. Developers using tools such as netstat to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors.

See JDK-8198562

Since build 2  Integrations

 Remove property sun.locale.formatasdefault

The system property sun.locale.formatasdefault, which was introduced in JDK 7 for the backward compatibility, has now been removed.

See JDK-8198385

Since build 1  Integrations

 jarsigner should print when a timestamp will expire

The jarsigner tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year.

See JDK-8191438
 Support AES Encryption with HMAC-SHA2 for Kerberos 5 defined in RFC 8009

The Kerberos 5 encryption types "aes128-cts-hmac-sha256-128" and "aes256-cts-hmac-sha384-192" as defined in RFC 8009 are supported. These encryption types are enabled by default and the default preference order is "aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 des3-cbc-sha1 arcfour-hmac-md5 des-cbc-crc des-cbc-md5". Users can use the default_tkt_enctypes and default_tgs_enctypes settings in the krb5.conf file to modify the list.

See JDK-8014628
 ThreadPoolExecutor should not specify a dependency on finalization

Previous versions of ThreadPoolExecutor had a finalize method that shut down the thread pool, but in this version the finalize method does nothing. This should have no visible effect unless a subclass explicitly invokes the finalize method and relies on the executor being shutdown.

See JDK-8190324
 filterArguments runs multiple filters in the wrong order

The specification of the method java.lang.invoke.MethodHandles.filterArguments was clarified to state more clearly that filter arguments are invoked in left to right order. The implementation of this method was also fixed to ensure it conformed to the specification. Prior to the fix the implementation incorrectly invoked filters in right to left order. For the majority of usages it is expected such a change in behavior will not be observable. Only in the minority of cases where two or more filters have side-effects that affect their results will such behavior be observable.

See JDK-8194554
 Remove sun.nio.ch.disableSystemWideOverlappingFileLockCheck property

JDK 6 introduced the system property sun.nio.ch.disableSystemWideOverlappingFileLockCheck to control file locking behavior, specifically to enable suppression of JVM-wide file locking so as to provide compatibility with JDK 1.4 and JDK 5. The old behavior was constrained to check for locks obtained on the channel instance only, not JVM-wide which is what was actually specified. As of JDK 11 the property sun.nio.ch.disableSystemWideOverlappingFileLockCheck is removed and the compatibility with the older locking approach therefore removed.

See JDK-8196535
 Removal of the Java EE and CORBA Modules

The following modules have been removed from Java SE 11 and JDK 11:

java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services Metadata) java.xml.bind (JAXB) java.activation (JAF) java.xml.ws.annotation (Common Annotations) java.corba (CORBA) java.transaction (JTA) java.se.ee (Aggregator module for the six modules above) jdk.xml.ws (Tools for JAX-WS) jdk.xml.bind (Tools for JAXB)

The following JAX-WS tools, from the jdk.xml.ws module, are removed:

The rmic compiler was updated to remove the -idl and -iiop options. Consequently, the RMI compiler will no longer be able to generate IDL or IIOP stubs and tie classes.

In addition, the following system properties are no longer applicable due to the the removal of the Java EE and CORBA modules:

For more detailed information on the removal and possible replacement for the modules, refer to JEP 320.

JDK-8190378 (not public)

Not Yet Integrated

 Better stack walking

New access checks have been added during the object creation phase of deserialization. This should not affect ordinary uses of deserialization. However, reflective frameworks that make use of JDK-internal APIs may be impacted. The new checks can be disabled if necessary by setting the system property jdk.disableSerialConstructorChecks to the value "true". This must be done by adding the argument -Djdk.disableSerialConstructorChecks=true to the Java command line.

JDK-8197925 (not public)


 Remove support for libavcodec 53 and 55

Support for libavcodec 53 and 55 was removed.

See JDK-8194062
 URLClassLoader does not specify behavior when URL array contains null

URLClassLoader's constructors are specified to throw NullPointerException if the URL array includes a null element.

See JDK-8198803
 Local-Variable Syntax for Lambda Parameters

JEP 323: Local-Variable Syntax for Lambda Parameters allows var to be used when declaring the formal parameters of implicitly typed lambda expressions. Former JEP 286: Local-Variable Type Inference, enhanced the Java Language to extend type inference to declarations of local variables with initializers, allowing the declaration of local variables without a explicit type name. So the main purpose of JEP 323 is to align the syntax of a formal parameter declaration in an implicitly typed lambda expression with the syntax of a local variable declaration.

So a var applied to a formal parameter of an implicitly typed lambda expression is ignored and the inferred type will be exactly the same as not using var at all. Like the distinction between implicit and explicit lambdas itself, using this syntax is all-or-nothing; either all parameters must be declared with var, or none.

For formal parameters of implicitly typed lambda expressions, javac now allows the reserved type name var to be used, so that:

(var x, var y) -> x.process(y)

is equivalent to:

(x, y) -> x.process(y)

An implicitly typed lambda expression must use var for all its formal parameters or for none of them. In addition, var is permitted only for the formal parameters of implicitly typed lambda expressions --- explicitly typed lambda expressions continue to specify manifest types for all their formal parameters, so it is not permitted for some formal parameters to have manifest types while others use var. The following examples are illegal:

(var x, y) -> x.process(y)         // Cannot mix 'var' and 'no var' in implicitly typed lambda expression
(var x, int y) -> x.process(y)     // Cannot mix 'var' and manifest types in explicitly typed lambda expression

In theory, it would be possible to have a lambda expression like the last line above, which is semi-explicitly typed (or semi-implicitly typed, depending on your point of view). However, it is outside the scope of JEP 323 because it deeply affects type inference and overload resolution. This is the main reason for keeping the restriction that a lambda expression must specify all manifest parameter types or none. We also want to enforce that the type inferred for a parameter of an implicitly typed lambda expression is the same whether var is used or not. Also, we do not wish to compromise the brevity of the shorthand syntax, so we won't allow expressions like:

var x -> x.foo()
See JDK-8193259