JDK 11 Early-Access Release Notes

Last update: 2018/07/20

This is a draft of the release notes that will accompany JDK 11. The contents are subject to change until release.

Build 23

Add T-Systems, GlobalSign and Starfield Services root certificates (JDK-8199779)


The following root certificates have been added to the OpenJDK cacerts truststore:

DN: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2

DN: C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 3

DN: C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2

DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Services Root Certificate Authority - G2

DN: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA

DN: OU=GlobalSign Root CA - R3, O=GlobalSign, CN=GlobalSign

DN: OU=GlobalSign ECC Root CA - R5, O=GlobalSign, CN=GlobalSign

--add-exports no longer implies readability in javac (JDK-8207032)


Running javac with the --add-exports command line option will no longer automatically make the exporting module readable by the target module. Use the --add-reads option to let the target module read the exporting module if needed.

Build 20

New Collection.toArray(IntFunction) Default Method (JDK-8060192)


A new default method toArray(IntFunction) has been added to the java.util.Collection interface. This method allows the collection's elements to be transferred to a newly created array of a desired runtime type. The new method is an overload of the already-existing toArray(T[]) method that takes an array instance as an argument, creating a minor source incompatibility. Previously, code of the form coll.toArray(null) would always resolve to the already-existing toArray method. With the new overloaded method, this code is now ambiguous and will result in a compile-time error. (This is only a source incompatibility. Existing binaries are unaffected.) The ambiguous code should be changed to cast null to the desired array type, for example, toArray((Object[])null) or some other array type. Note that passing null to either toArray method is specified to throw NullPointerException.

Make some system properties effectively readonly (JDK-8066709)


The values of java.home, user.home, user.dir, and user.name properties are cached at startup. Changes made using System::setProperty after startup will not change the behavior of APIs in the java.base module.

Obsolete Support for Commercial Features (JDK-8202331)


The -XX:+UnlockCommercialFeatures and -XX:+LogCommercialFeatures command line arguments have been obsoleted, and will generate a warning message if used. The command line arguments used to control the use of and logging for commercial/licensed features in the VM. Since there are no such features anymore the command line arguments are no longer useful.

Similarly, the VM.unlock_commercial_features and VM.check_commercial_features jcmd commands will also generate a warning message but have no additional effect.

JEP 181 Nest-Based Access Control (JDK-8010319)


JEP-181: Nest-based access control

In Java SE 11, the Java Virtual Machine supports the arrangement of classes and interfaces into a new access control context, called a nest. Nests allow classes and interfaces that are logically part of the same code entity, but which are compiled to distinct class files, to access each other's private members without the need for compilers to insert accessibility-broadening bridge methods. Nests are a low-level mechanism of the Java SE Platform; there are no changes to the access control rules of the Java programming language. The javac compiler has been updated to use nests when compiling nested classes and interfaces in Java source code, by generating new class files attributes that place a top-level class (or interface) and all its nested classes and interfaces in the same nest. The Java Virtual Machine has been updated to use these attributes when checking the accessibility of a private constructor, method, or field, including via core reflection and the java.lang.invoke.MethodHandles.Lookup API. Membership in a nest is exposed through the new getNestHost and getNestMembers methods of java.lang.Class.

As nest membership is recorded in the class file of the top-level class or interface (the nest host), that class file must be present at run time to allow the access control checks to be performed. This is not normally a concern as the top-level class or interface is typically used directly. In some code where a top-level class or interface acts only as a holder for nested classes or interfaces, and is otherwise unused, packaging tools may have elided that class file from the distribution of a library or application. With nest-based access control, it is no longer possible to elide the top-level class or interface if any of the nested classes or interfaces require access to each other's private members — a NoClassDefFoundError or ClassNotFoundException will be thrown.

JFR start failure after AppCDS archive created with JFR StartFlightRecording (JDK-8203664)


JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message:

Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during CDS dumping

if JFR is enabled during CDS dumping such as in the following command line:

$java -Xshare:dump -XX:StartFlightRecording=dumponexit=true

Add RSASSA-PSS Signature support to SunMSCAPI (JDK-8205445)


The RSASSA-PSS signature algorithm support is added to the SunMSCAPI provider.

Change to policy for the default set of modules resolved when compiling or running code on the class path (JDK-8197532)


The default set of root modules when compiling code or running code on the class path has changed in JDK 11 to be all observable system modules that export an API. The only observable change is that the java.se module is no longer resolved by default.

Build 19

Deprecate pack200 and unpack200 tools (JDK-8199871)


The pack200 API and the tools associated with it, pack200 and unpack200 have been deprecated and it is planned to remove them in a future release.

Those tools are still included in JDK11, but will no longer be updated to support latest class file format. Class files with unknown attributes will be passed-through without compression.

Packages not visible in imports are rejected (JDK-8193302)


Imports that import from packages that are not visible in the current module but whose names are prefixes of names of visible packages used to be accepted by javac. These will now be rejected when compiling with -source >= 9.

Update xmldsig implementation to Apache Santuario 2.1.1 (JDK-8177334)


The XMLDSig provider implementation in the java.xml.crypto module has been updated to version 2.1.1 of Apache Santuario. New features include:

  1. Support for the SHA-224 and SHA-3 DigestMethod algorithms specified in RFC 6931.
  2. Support for the HMAC-SHA224, RSA-SHA224, ECDSA-SHA224, and RSASS-PSS family of SignatureMethod algorithms specified in RFC 6931.

G1 enables adaptive parallel reference processing by default (JDK-8205043)


G1 determines an optimal number of threads to use for java.lang.ref.Reference processing during garbage collection by default. The flag -XX:ParallelRefProcEnabled is now true (enabled) by default.

This improves this phase of the garbage collection pause significantly on machines with more than one thread available for garbage collection.

If you experience increased garbage collection pauses you can revert to the original behavior by specifying -XX:-ParallelRefProcEnabled on the command line. The adaptiveness of the java.lang.ref.Reference processing can be tuned via the experimental option -XX:ReferencesPerThread (default value: 1000).

Fail immediately if a GC that is unavailable is selected (JDK-8205064)


Previously, if an unavailable garbage collector (e.g. the G1 garbage collector is not present in "minimal" JVM builds) was selected by the user on the command line, then the JVM would issue a warning and continue execution, by silently selecting one of the available garbage collectors. This behavior has been changed, such that the JVM will now print an error message and immediately terminate if the user selected an unavailable garbage collector.

Update locale data to Unicode CLDR v33 (JDK-8202537)


The locale data based on the Unicode Consortium's CLDR (Common Locale Data Registry) has been updated for JDK 11. Localized digits that are in supplementary planes (such as, those in Indian Chakma script) are substituted with ASCII digits until JDK-8204092 is resolved.

For more detail on CLDR release 33, please refer to [http://cldr.unicode.org/index/downloads/cldr-33] (http://cldr.unicode.org/index/downloads/cldr-33).

Build 18

Add GoDaddy root certificates (JDK-8196141)


The following root certificates have been added to the OpenJDK cacerts truststore:

DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., 
                CN=Go Daddy Root Certificate Authority - G2

DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority

DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority

DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., 
                CN=Starfield Root Certificate Authority - G2

remove Thread.destroy() and Thread.stop(Throwable) (JDK-8204243)


The methods Thread.destroy() and Thread.stop(Throwable) have been removed. They have both been deprecated for several Java SE releases. Thread.destroy() has never been implemented, and Thread.stop(Throwable) has been non-functional since Java SE 8, so no code can be relying on the behavior of these methods. However, code that uses these methods will cause compilation errors. The mitigation is to remove references to these methods from the source code. Note that the no-arg method Thread.stop() is unaffected by this change.

Oracle JDK's javax.imageio JPEG plugin no longer supports images with alpha (JDK-8204187)


Oracle JDK has previously used proprietary extensions to the widely used IJG JPEG library to provide optional color space support. This was used to support PhotoYCC and images with alpha component on both reading and writing. This optional support has been removed in Oracle JDK 11. Encountering already encoded JPEG images in any of these formats is very unlikely, unless they were previously encoded by an earlier version of the Oracle JDK. However in the case that they are encountered, decoding will now fail with an exception. Writing image with an alpha channel will also fail with an exception. This is the most probable scenario for problems for applications which previously could be unaware that they were relying on this support. This could fail with an exception, if the ImageWriter is called directly, or if using the Image I/O convenience methods, the write() method will now return false meaning it did not write the image. A carefully written application should be checking for these scenarios which will mitigate this. Also note that the OpenJDK has never had this optional proprietary support and has always failed and generated exceptions in these scenarios.

For detailed information on what is no longer supported refer to the optional color space support in the Java Image I/O JPEG Metadata specification : https://docs.oracle.com/javase/10/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color

Japanese New Era Implementation (JDK-8202088)


Japanese calendars, both in java.time.chrono and java.util packages support the upcoming Japanese new era, which will be in effect from May 1st, 2019. At the moment, the name of the era is not yet known, placeholder names ("元号" for Japanese, "NewEra" for other languages) are provided for its display names. The placeholder names will be replaced with the legitimate era name in a future update, thus applications should not depend on those placeholder names. Use integer values to refer to the new era instead. For example:

java.time.chrono.JapaneseEra.of(3).getDisplayName(TextStyle.FULL, Locale.US)


new java.util.Calendar.Builder()
    .setFields(Calendar.ERA, 5,
        Calendar.YEAR, 1,
        Calendar.MONTH, Calendar.MAY,
        Calendar.DAY_OF_MONTH, 1)
    .getDisplayName(Calendar.ERA, Calendar.LONG, Locale.US)

will output "NewEra"

Build 17

Remove Baltimore Cybertrust Code Signing CA (JDK-8189949)


The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed:

  • baltimorecodesigningca

    DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE

Remove several Symantec Root CAs (JDK-8191031)


The following Symantec root certificates are no longer in use and have been removed:

  • equifaxsecureca

    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US

  • equifaxsecureglobalebusinessca1

    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US

  • equifaxsecureebusinessca1

    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US

  • verisignclass1g3ca

    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  • verisignclass2g3ca

    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  • verisignclass1g2ca

    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

  • verisignclass1ca

    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

Deprecate stream-based GSSContext methods (JDK-8072996)


The stream-based methods in GSSContext have been deprecated in this release since GSS-API works on opaque tokens and has not defined a wire protocol. This includes the overloaded forms of the initSecContext, acceptSecContext, wrap, unwrap, getMIC, and verifyMIC methods that have an InputStream argument. These methods have already been removed in RFC 8353.

NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled (JDK-8187289)


A NotifyFramePop request was only cleared if the JVMTI_EVENT_FRAME_POP is enabled. Now it is always cleared when the corresponding frame is popped, regardless of whether the JVMTI_EVENT_FRAME_POP is enabled or not.

Build 16

Remove SECOM root (JDK-8191844)


The following SECOM root certificate is no longer in use and has been removed:

  • secomevrootca1

    DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP

Build 15

Kerberos sequence number issues (JDK-8201627)


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.

Build 13

Support for Unicode 10.0.0 (JDK-8191410)


The JDK 11 release includes support for Unicode 10.0.0. Since the release of JDK 10, which supported Unicode 8.0.0, JDK 11 combines Unicode 9.0.0 and 10.0.0 versions including:

  • 16,018 new characters
  • 18 new blocks
  • 10 new scripts

16,018 new characters include important additions for:

  • 19 symbols for the new 4K TV standard

  • Bitcoin sign
  • 128 emoji characters

10 new scripts :

  • Adlam
  • Bhaiksuki
  • Marchen
  • Newa
  • Osage
  • Tangut
  • Masaram Gondi
  • Nushu
  • Soyombo
  • Zanabazar Square

18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts:

  • Cyrillic Extended-C
  • Mongolian Supplement
  • Ideographic Symbols and Punctuation
  • Tangut Components
  • Glagolitic Supplement
  • Syriac Supplement
  • Kana Extended-A
  • CJK Extension F

java.lang.ref.Reference does not support cloning (JDK-8201793)


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.

Removal of appletviewer launcher (JDK-8200146)


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

Build 11

SelectableChannel.register may be invoked while a selection operation is in progress (JDK-8201315)


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.

Lazy allocation of compiler threads (JDK-8198756)


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:


Build 10

Extend class-data sharing to support the module path (JDK-8194812)


In JDK 11, Class Data Sharing (CDS) has been improved to support archiving classes from the module path.

To create a CDS archive using the --module-path vm option, the command line syntax is as follows:

$ java -Xshare:dump -XX:SharedClassListFile=<class list file> \
    -XX:SharedArchiveFile=<shared archive file> \
    --module-path=<path to modular jar> -m <module name>

To run with a CDS archive using the --module-path vm option, the command line syntax is as follows:

$ java -Xshare:on -XX:SharedArchiveFile=<shared archive file> \
    --module-path=<path to modular jar> -m <module name>

The following table describes how the VM options related to module paths may be used along with the -Xshare option.

-Xshare:dump -Xshare:{on,auto}
--module-path1 <mp> Allowed Allowed2
--module Allowed Allowed
--add-module Allowed Allowed
--upgrade-module-path3 Disallowed (exits if specified) Allowed (disables CDS)
--patch-module4 Disallowed (exits if specified) Allowed (disables CDS)
--limit-modules5 Disallowed (exits if specified) Allowed (disables CDS)

1Although there are two ways of specifying a module in a --module-path, that is, modular jar or exploded module, only modular jars are supported.

2Different <mp> may be specified during dump time vs run time. If an archived class K was loaded from mp1.jar at dump time, but changes in <mp> cause it to be available from a different mp2.jar at run time, then the archived version of K will be disregarded at run time; K will be loaded dynamically.

3Currently, only two system modules are upgradeable (java.compiler and jdk.internal.vm.compiler). These are seldom upgraded in production software.

4As documented in JEP 261, --patch-module is strongly discouraged for production use.

5--limit-modules is intended for testing purposes. It is seldom used in production software.

If any of --upgrade-module-path, --patch-module or --limit-modules is specified at dump time, the following error will be printed and the JVM will exit. For example, if the --limit-modules option is specified at dump time, the user will see the following error:

Error occurred during initialization of VM
Cannot use the following option when dumping the shared archive: --limit-modules

If any of --upgrade-module-path, --patch-module or --limit-modules is specified at run time, the following warning message will be printed indicating that CDS is disabled. For example, if the --limit-modules options is specified at run time, the user will see the following warning:

Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified.

A few other noteworthy things to mention:

  1. Any valid combinations of -cp and --module-path is supported.

  2. A non-empty directory in the module path causes fatal error. The user will see the following error messages:

    Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths

  3. Unlike the class path, there's no restriction that the module path at dump time must be equal to or be a prefix of the module path at run time.

  4. The archive is invalidated if an existing JAR in the module path is updated after archive generation.

  5. Removing a JAR from the module path does not invalidate the shared archive. Archived classes from the removed JAR are not used at runtime.

Removal of "com.sun.awt.AWTUtilities" class (JDK-8200149)


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

Build 9

Remove SNMP agent (JDK-8071367)


jdk.snmp module has been removed.

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

  • com.sun.management.snmp.port
  • com.sun.management.snmp.trap
  • com.sun.management.snmp.interface
  • com.sun.management.snmp.acl
  • com.sun.management.snmp.acl.file

KerberosString uses UTF-8 encoding by default (JDK-8200152)


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.

Readiness information previously recorded in SelectionKey ready set not preserved (JDK-8200458)


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.

Build 7

GTK3 is now the default on Linux/Unix. (JDK-8198649)


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

Better stability with older NUMA libraries (-XX+UseNuma) (JDK-8198794)


A fix included in JDK 8 Update 152 introduced a regression that might cause the HotSpot JVM to crash during startup when the UseNUMA flag is used on Linux systems with versions of libnuma older than 2.0.9. This issue has been resolved.

DatagramChannel.send throws AlreadyConnectedException instead of IllegalArgumentException (JDK-8198753)


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.

Deprecate -XX+AggressiveOpts (JDK-8199777)


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.

Garbage collectors adaptively scale the number of threads by default (JDK-8198510)


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.

New PerfCounters for STW phases on Concurrent GC are available (JDK-8153333)


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:

  • G1 includes remark and cleanup pauses
  • CMS includes initial mark and remark pauses

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.

Build 6

remove terminally deprecated sun.misc.Unsafe.defineClass (JDK-8193033)


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:


Build 4

javax.transaction.xa package moved to the java.transaction.xa module (JDK-8197533)


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:

  • javax.transaction.xa.XAResource
  • javax.transaction.xa.Xid
  • javax.transaction.xa.XAException

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

Missing types consistently modeled as ERROR types (JDK-8187950)


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.

Build 3

(ch) Separate blocking and non-blocking code paths (JDK-8198562)


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.

Build 2

Remove property sun.locale.formatasdefault (JDK-8198385)


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

Build 1

Add Entrust root certificates (JDK-8195774)


The following root certificates have been added to the OpenJDK cacerts truststore:

DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, 
        OU=(c) 2012 Entrust, Inc. - for authorized use only,
        CN=Entrust Root Certification Authority - EC1

DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),
        OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)

DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms,
        OU=(c) 2009 Entrust, Inc. - for authorized use only,
        CN=Entrust Root Certification Authority - G2

DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference,
        OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority

DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking

DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium

DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial

DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC

Support AES Encryption with HMAC-SHA2 for Kerberos 5 defined in RFC 8009 (JDK-8014628)


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.

JVM Crash during G1 GC (JDK-8187577)


A klass that has been considered unreachable by the concurrent marking of G1, can be looked up in the ClassLoaderData/SystemDictionary, and its _java_mirror or _class_loader fields can be stored in a root or any other reachable object making it alive again. Whenever a klass is resurrected in this manner, the SATB part of G1 needs to be notified about this, otherwise, the concurrent marking remark phase will erroneously unload that klass.

In this particular crash, while G1 was doing concurrent marking and had prepared its list of unreachable classes, JVMTI on a Java thread could traverse classes in the CLD and store thread-local JNIHandles for the java_mirror of the loaded classes. G1 did not have knowledge of these thread-local JNIHandles, and in the remark phase, it unloaded classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash.

This fix for JDK-8187577 informs G1's SATB that a klass has been resurrected and should not be unloaded.

filterArguments runs multiple filters in the wrong order (JDK-8194554)


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 that 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 that the change in behavior will not be observable. Only in a minority of cases, where two or more filters have side-effects that affect their results, will the change in behavior be observable.

Remove sun.nio.ch.disableSystemWideOverlappingFileLockCheck property (JDK-8196535)


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.

jarsigner should print when a timestamp will expire (JDK-8191438)


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.

ThreadPoolExecutor should not specify a dependency on finalization (JDK-8190324)


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.

Removal of the Java EE and CORBA Modules (JDK-8190378)


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:

  • wsgen
  • wsimport

The following JAXB tools, from the jdk.xml.bind module, are removed:

  • schemagen
  • xjc

The following CORBA tools, from the java.corba module, are removed:

  • idlj
  • orbd
  • servertool
  • tnamesrv

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:

  • com.sun.xml.internal.ws.client.ContentNegotiation
  • com.sun.xml.internal.ws.legacyWebMethod
  • javax.xml.bind.context.factory
  • javax.xml.bind.JAXBContext
  • javax.xml.soap.MetaFactory
  • javax.xml.ws.spi.Provider
  • jaxb.fragment
  • jaxb.noNamespaceSchemaLocation
  • jaxb.schemaLocation
  • jaxb.formatted.output
  • jaxb.encoding
  • mail.mime.decodetext.strict
  • mail.mime.encodeeol.strict
  • mail.mime.foldencodedwords
  • mail.mime.foldtext
  • mail.mime.charset
  • saaj.mime.optimization
  • saaj.lazy.contentlength
  • saaj.lazy.contentlength
  • saaj.lazy.mime.optimization

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

Not Yet Integrated

URLClassLoader does not specify behavior when URL array contains null (JDK-8198803)


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


Local-Variable Syntax for Lambda Parameters (JDK-8193259)


The reserved type name var can now be used when declaring the formal parameters of a lambda expression. This builds on the ability in Java SE 10 to use var when declaring local variables.

Using var for a formal parameter of a lambda expression causes the type of the parameter to be inferred, using the same rules as when neither var nor an explicit type is present. (Lambda expressions have allowed their formal parameters to be declared without explicit types since Java SE 8.)

If var is used for any formal parameter of a lambda expression, then it must be used for all formal parameters of that lambda expression.

Deprecate Nashorn implementation, APIs, and jjs tool (JDK-8202786)

The Nashorn JavaScript Engine implementation, the APIs and the jjs shell tool have been deprecated and might be removed in a future release. Code that uses classes and interfaces from jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages will get a deprecation warning from javac.

The Nashorn engine (when used by javax.script API or jrunscript tool) as well as jjs shell tool will print a warning message about deprecation. To disable this runtime warning message, users can include the new Nashorn option, --no-deprecation-warning. This may be useful for compatibility scripts that depend on exact output (such as, to avoid the warning breaking their exact output expected).

JEP 333 ZGC A Scalable Low-Latency Garbage Collector (Experimental) (JDK-8197831)


The Z Garbage Collector, also known as ZGC, is a new scalable low latency garbage collector designed to meet the following goals:

  • Pause times do not exceed 10 ms
  • Pause times do not increase with the heap or live-set size
  • Handle heaps ranging from a few hundred megabytes to multi terabytes in size

At its core, ZGC is a concurrent garbage collector, meaning all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the impact garbage collection will have on application response times.

ZGC is included as an experimental feature. To enable it, the -XX:+UnlockExperimentalVMOptions will therefore be needed in combination with -XX:+UseZGC.

This experimental version of ZGC has the following limitations:

  • It is only available on Linux/x64.

  • Using compressed oops and/or compressed class points is not supported. The -XX:+UseCompressedOops and -XX:+UseCompressedClassPointers options are disabled by default. Enabling them will have no effect.

  • Class unloading is not supported. The -XX:+ClassUnloading and -XX:+ClassUnloadingWithConcurrentMark options are disabled by default. Enabling them will have no effect.

  • Using ZGC in combination with Graal is not supported.