JDK 11 Early-Access Release Notes

Last Update: 2018/09/18

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

Build 27

Added Google Trust Services GlobalSign Root Certificates (JDK-8209506)

security-libs/java.security

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

  • Google
    • globalsigneccrootcar4

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

    • globalsignr2ca

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

Build 23

Added T-Systems, GlobalSign and Starfield Services Root Certificates (JDK-8199779)

security-libs/java.security

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

  • T-Systems

    • deutschetelekomrootca2

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

    • ttelesecglobalrootclass3ca

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

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

  • Amazon

    • starfieldservicesrootg2ca

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

  • GlobalSign

    • globalsignca

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

    • globalsignr3ca

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

    • globalsigneccrootcar5

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

--add-exports No Longer Implies Readability in javac (JDK-8207032)

tools/javac

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

Build 20

Added Brainpool EC Support (RFC 5639) (JDK-7007966)

security-libs/javax.crypto

The SunEC provider has been enhanced to support 4 additional Brainpool curves as defined in RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation. The corresponding EC domain parameters can be created by using java.security.spec.ECGenParameterSpec objects with standard names of brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, and brainpoolP512r1. Note that the SunJSSE provider has not yet been enhanced to support these brainpool curves.

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

core-libs/java.util:collections

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 existing toArray(T[]) method that takes an array instance as an argument. The addition of the overloaded method creates a minor source incompatibility. Previously, code of the form coll.toArray(null) would always resolve to the 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)

core-libs/java.lang

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)

hotspot/runtime

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)

hotspot/runtime

Introduce nests, an access-control context that aligns with the existing notion of nested types in the Java programming language (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)

hotspot/runtime

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

RSASSA-PSS Signature Support Added to SunMSCAPI (JDK-8205445)

security-libs/javax.crypto

The RSASSA-PSS signature algorithm support has been 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)

core-libs/java.lang.module

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

Method ClassgetAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present (JDK-7183985)

core-libs/java.lang

When java.lang.Class::getAnnotation is called to retrieve an annotation, and the annotation has an array value that references a missing class, attempting to read that value results in a java.lang.TypeNotPresentException.

In previous releases the call to Class::getAnnotation incorrectly resulted in a java.lang.ArrayStoreException. Any programs that explicitly handled that exception should be updated to handle java.lang.TypeNotPresentException instead.

JEP 336 Deprecate the Pack200 Tools and API (JDK-8199871)

tools

Deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar (JEP 336).

The pack200 API and the tools associated with it, pack200 and unpack200, have been deprecated and will be removed in a future release.

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

Packages Not Visible in Imports Are Rejected (JDK-8193302)

tools/javac

javac used to accept imports from packages that were not visible in the current module but whose names were prefixes of names of visible packages. These are now rejected when compiling with -source >= 9.

Updated xmldsig Implementation to Apache Santuario 2.1.1 (JDK-8177334)

security-libs/javax.xml.crypto

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)

hotspot/gc

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

The change 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 java.lang.ref.Reference processing can be tuned by using the experimental option, -XX:ReferencesPerThread (default value: 1000).

Fail Immediately If a GC That Is Unavailable Is Selected (JDK-8205064)

hotspot/gc

Previously, if an unavailable garbage collector (for example, the G1 garbage collector was 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. The JVM will now print an error message and immediately terminate if the user selects an unavailable garbage collector.

Updated Locale Data to Unicode CLDR v33 (JDK-8202537)

core-libs/java.util:i18n

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. Medium and short time patterns for Burmese locale have not been upgraded. When JDK-8209175 is resolved, these patterns will be upgraded.

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

Build 18

Added GoDaddy Root Certificates (JDK-8196141)

security-libs/java.security

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

  • GoDaddy
    • godaddyrootg2ca

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

    • godaddyclass2ca

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

    • starfieldclass2ca

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

    • starfieldrootg2ca

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

Removal of Thread.destroy() and Thread.stop(Throwable) Methods (JDK-8204243)

core-libs/java.lang

The methods Thread.destroy() and Thread.stop(Throwable) have been removed. They have been deprecated for several Java SE releases. The Thread.destroy() method has never been implemented, and the Thread.stop(Throwable) method has been non-functional since Java SE 8. No code should rely on the behavior of these two methods; however, any 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.

Japanese New Era Implementation (JDK-8202088)

core-libs/java.util:i18n

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)

or

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

will output "NewEra"

Build 17

Removal of Baltimore Cybertrust Code Signing CA (JDK-8189949)

security-libs/java.security

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

Removal of Several Symantec Root CAs (JDK-8191031)

security-libs/java.security

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

  • Symantec
    • 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)

security-libs/org.ietf.jgss

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)

hotspot/jvmti

In the previous release, a NotifyFramePop request was only cleared when the JVMTI_EVENT_FRAME_POP was 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

Removal of SECOM Root Certificate (JDK-8191844)

security-libs/java.security

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)

security-libs/org.ietf.jgss:krb5

Previously, when mutual authentication 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

JEP 327 Unicode 10 (JDK-8191410)

core-libs/java.lang

Upgrade existing platform APIs to support version 10.0 of the Unicode Standard (JEP 327: Unicode 10).

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)

core-libs/java.lang

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)

client-libs/java.awt

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

Build 11

SelectableChannel.register Can Be Invoked While a Selection Operation Is in Progress (JDK-8201315)

core-libs/java.nio

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)

hotspot/compiler

A new command line flag -XX:+UseDynamicNumberOfCompilerThreads has been added to dynamically control 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 the available memory and the number of compilation requests. Because the threads consume memory even when they are idle (which is almost all of the time), this leads to an inefficient use of resources.

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

-XX:+UseDynamicNumberOfCompilerThreads

Build 10

Extend Class Data Sharing (CDS) to Support the Module Path (JDK-8194812)

hotspot/runtime

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 .jar files 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 one 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 one 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 option 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 are supported.

  2. A non-empty directory in the module path causes a 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)

client-libs

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

Build 9

supported_groups Extension Should Not be Present in ServerHello Handshake Message (JDK-8209965)

security-libs/javax.net.ssl

While the supported_groups extension should not be present in ServerHello handshake messages, previous releases have ignored its presence, so that misconfigured servers could continue to function. JDK 11 currently throws an exception if this extension is sent in the ServerHello handshake message.

KerberosString Uses UTF-8 Encoding by Default (JDK-8200152)

security-libs/org.ietf.jgss:krb5

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)

core-libs/java.nio

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)

client-libs/java.awt

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

Previously, the JDK would default to loading the older GTK2 libraries. However, 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 the system property: -Djdk.gtk.version=2.2

Better Stability with Older NUMA Libraries (-XX+UseNuma) (JDK-8198794)

hotspot/gc

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)

core-libs/java.nio

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. In Java SE 11, the specification has been clarified to specify java.nio.channels.AlreadyConnectedException for this case, and the implementation has been changed to throw the correct exception.

Deprecate -XX+AggressiveOpts (JDK-8199777)

hotspot/compiler

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 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 their corresponding flags from 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)

hotspot/gc

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)

hotspot/gc

A new GC performance counter has been added for pauses during the concurrent phase. This counter will be listed by jstat under the CGC (concurrent GC) heading. This information is only available for GCs with a concurrent phase and 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 by using PerfCounter.print.

Build 6

Removal of sun.misc.Unsafe.defineClass (JDK-8193033)

core-libs

The sun.misc.Unsafe.defineClass class has been removed. Users should use the public replacement, java.lang.invoke.MethodHandles.Lookup.defineClass, added in Java SE 9. For more details see the Java documentation:

https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A-

Build 4

javax.transaction.xa Package Moved to the java.transaction.xa Module (JDK-8197533)

other-libs

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 has been moved 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 Are Consistently Modeled as ERROR Types (JDK-8187950)

tools/javac

Missing types are now consistently modeled as ERROR types, and the javac internal exception, CompletionFailure, is no longer thrown to API clients. Previously, annotation processors and other javax.lang.model clients could, in some cases, observe missing types modeled as DECLARED types with a javac internal exception, CompletionFailure, thrown out of the model methods when manipulating such types.

Build 3

Removal of AOL and Swisscom Root Certificates (JDK-8203230)

security-libs/java.security

The following root certificates have been removed from the cacerts truststore:

  • AOL

    • aolrootca1

      DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US

    • aolrootca2

      DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US

  • Swisscom

    • swisscomrootca2

      DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch

Separate Blocking and Non-blocking Code Paths (JDK-8198562)

core-libs/java.nio

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. 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. Similarly, closing a ServerSocketChannel that is registered with Selector will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous 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.

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

Build 2

Removal of sun.locale.formatasdefault Property (JDK-8198385)

core-libs/java.util:i18n

The system property sun.locale.formatasdefault, introduced in JDK 7 for backwards compatibility, has been removed.

Build 1

Added Entrust Root Certificates (JDK-8195774)

security-libs/java.security

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

  • Entrust
    • entrustrootcaec1

      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

    • entrust2048ca

      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)

    • entrustrootcag2

      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

    • entrustevca

      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

    • affirmtrustnetworkingca

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

    • affirmtrustpremiumca

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

    • affirmtrustcommercialca

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

    • affirmtrustpremiumeccca

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

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

security-libs/org.ietf.jgss:krb5

The Kerberos 5 encryption types of aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192 defined in RFC 8009 are supported. These encryption types are enabled by default. The default order of preference 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.

filterArguments Runs Multiple Filters in the Wrong Order (JDK-8194554)

core-libs/java.lang.invoke

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.

Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property (JDK-8196535)

core-libs/java.nio

The property sun.nio.ch.disableSystemWideOverlappingFileLockCheck has been removed. Consequently, compatibility with the older locking approach has also been removed.

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

jarsigner Prints When a timestamp Will Expire (JDK-8191438)

security-libs/java.security

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)

core-libs/java.util.concurrent

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.

JEP 320 Remove the Java EE and CORBA Modules (JDK-8190378)

other-libs

Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9 with the declared intent to remove them in a future release (JEP 320).

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

TLS 1.3 Half-Close Policy (JDK-8208526)

security-libs/javax.net.ssl

A new system property, jdk.tls.acknowledgeCloseNotify, has been added. The default value of the system property is false. If the system property is set to true, a corresponding close_notify alert will be sent when receiving a close_notify alert, and the connection will be duplex closed.

TLS 1.2 and prior versions use a duplex-close policy, while TLS 1.3 uses a half-close policy. The inbound and the outbound close_notify alerts for TLS 1.3 are independent. When upgrading to TLS 1.3, unexpected behavior can occur if your application shuts down the (D)TLS connection by using only one of the SSLEngine.closeInbound() or SSLEngine.closeOutbound() APIs, but not both in each side of the connection. If your application exhibits unexpected hangs or timeouts when the underlying (D)TLS transportation is not duplex closed, you may need to set this property to true.

Note that when a TLS/DTLS connection is no longer needed, the client and server applications should each close both sides of their respective connection.

URLClassLoader Does Not Specify Behavior When URL Array Contains null (JDK-8198803)

core-libs/java.net

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

Delivered

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

specification/language

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.

JEP 332 Transport Layer Security (TLS) 1.3 (JDK-8145252)

security-libs/javax.net.ssl

The JDK 11 release includes an implementation of the Transport Layer Security (TLS) 1.3 specification (RFC 8446). For more details including a list of the features that are supported, refer to the Java Secure Socket Extension (JSSE) Reference Guide documentation and JEP 332.

For TLS 1.3, the following new standard algorithm names are defined:

  1. TLS protocol version name: TLSv1.3
  2. SSLContext algorithm name: TLSv1.3
  3. TLS cipher suite names for TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384
  4. keyType for X509KeyManager: RSASSA-PSS
  5. authType for X509TrustManager: RSASSA-PSS

A new Security Property, jdk.tls.keyLimits, has been added for TLS 1.3. When the specified amount of data of a specific algorithm has been processed, a post-handshake Key and IV Update is triggered to derive new keys.

A new System Property, jdk.tls.server.protocols, has been added to configure the default enabled protocol suite in server side of SunJSSE provider.

Note that the KRB5 cipher suites implementation has been removed from the JDK because they are no longer considered safe to use.

Note that TLS 1.3 is not directly compatible with previous versions. Although TLS 1.3 can be implemented with a backward-compatibility mode, there are still several compatibility risks to take into account when upgrading to TLS 1.3:

  1. TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there may be compatibility issues when upgrading to TLS 1.3.
  2. The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use unsupported signature algorithms.
  3. The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3.
  4. The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites which are no longer supported, it may not be able to use TLS 1.3 without modifying the application code.
  5. The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility impact should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols.

The System properties, jdk.tls.client.protocols and jdk.tls.server.protocols, can be used to configure the default enabled protocols accordingly in the SunJSSE provider if needed.

JEP 335 Deprecate the Nashorn JavaScript Engine (JDK-8202786)

Deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release (JEP 335).

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 might be useful for compatibility scripts that depend on exact output (such as, to avoid the warning breaking their expected exact output).

JEP 329 ChaCha20 and Poly1305 Cryptographic Algorithms (JDK-8153028)

security-libs/javax.crypto

Implement the ChaCha20 and ChaCha20-Poly1305 ciphers as specified in RFC 7539. ChaCha20 is a newer stream cipher that can replace the older, insecure RC4 stream cipher.

Those wishing to obtain an instance of the ChaCha20 stream cipher may use the algorithm string "ChaCha20" with the Cipher.getInstance method. Those wishing to use ChaCha20 in AEAD mode with the Poly1305 authenticator may use the algorithm string "ChaCha20-Poly1305". See the "Java Security Standard Algorithm Names" document for more details.

JEP 324 Key Agreement with Curve25519 and Curve448 (JDK-8181595)

security-libs

JEP 324 adds an implementation of a new key agreement scheme using Curve25519 and Curve448 as described in RFC 7748. This implementation is available as a Java Cryptography Architecture service, but it has not been incorporated into the new TLS 1.3 implementation.

JEP 331 Low-Overhead Heap Profiling (JDK-8171119)

hotspot/jvmti

Provide a low-overhead way of sampling Java heap allocations, accessible via JVMTI (JEP 331).

It is designed to meet the following goals:

  • Low-overhead enough to be continuously enabled by default
  • Accessible via a well-defined, programmatic interface (JVMTI)
  • Can sample all allocations (that is, not limited to allocations that are in one particular heap region or that were allocated in one particular way)
  • Can be defined in an implementation-independent way (that is, without relying on any particular GC algorithm or VM implementation)
  • Can give information about both live and dead Java objects

JEP 330 Launch Single-File Source-Code Programs (JDK-8192920)

tools/launcher

Enhance the java launcher to run a program supplied as a single file of Java source code, including usage from within a script by means of "shebang" files and related techniques.

Important Changes (JDK-8209811)

  • Deployment Stack, required for Applets and Web Start Applications, was deprecated in JDK 9 and has been removed in JDK 11.
  • Without a deployment stack, the entire section of supported browsers has been removed from the list of supported configurations of JDK 11.
  • Auto-update, which was available for JRE installations on Windows and macOS, is no longer available.
  • In Windows and macOS, installing the JDK in previous releases optionally installed a JRE. In JDK 11, this is no longer an option.
  • In this release, the JRE or Server JRE is no longer offered. Only the JDK is offered. Users can use jlink to create smaller custom runtimes.
  • JavaFX is no longer included in the JDK. It is now available as a separate download from openjfx.io.
  • Java Mission Control, which was shipped in JDK 7, 8, 9, and 10, is no longer included with the Oracle JDK. It is now a separate download.
  • Previous releases were translated into English, Japanese, and Simplified Chinese as well as French, German, Italian, Korean, Portuguese (Brazilian), Spanish, and Swedish. However, in JDK 11 and later, French, German, Italian, Korean, Portuguese (Brazilian), Spanish, and Swedish translations are no longer provided.
  • Updated packaging format for Windows has changed from tar.gz to .zip, which is more common in Windows OSs.
  • Updated package format for macOS has changed from .app to .dmg, which is more in line with the standard for macOS.

JEP 321 HTTP Client (Standard) (JDK-8181784)

core-libs/java.net

Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10 (JEP 321).

The HTTP Client has been standarized in Java 11. As part of this work the previously incubating API, located in the jdk.incubator.http package, has been removed. At a very minimum, code that uses types from the jdk.incubator.http package will need to be updated to import the HTTP types from the standard package name, java.net.http.

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

hotspot/gc

The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector (JEP 333). It is 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 that all heavy lifting work (marking, compaction, reference processing, string table cleaning, etc) is done while Java threads continue to execute. This greatly limits the negative impact that garbage collection has on application response times.

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

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.

JEP 318 Epsilon, A No-Op Garbage Collector (JDK-8174901)

hotspot/gc

Epsilon GC is the new experimental no-op garbage collector. Epsilon GC only handles memory allocation, and does not implement any memory reclamation mechanism. It is useful for performance testing, to contrast costs/benefits of other GCs. It can be used to conveniently assert memory footprint and memory pressure in tests. In extreme cases, it might be useful with very short lived jobs, where memory reclamation would happen at JVM termination, or getting the last-drop latency improvements in low-garbage applications. See more discussion about its use and tradeoffs in JEP 318.