JDK 11 Release Notes

Introduction

The Release Notes describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 11 and Java SE 11. In some cases, the descriptions provide links to additional detailed information about an issue or a change. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 11 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. This page does not duplicate the descriptions provided by the Java SE 11 (18.9) ( JSR 384) Platform Specification, which provides informative background for all specification changes and might also include the identification of removed or deprecated APIs and features not described here. The Java SE 11 (18.9) ( JSR 384) specification provides links to:

• Annex 1: The complete Java SE 11 API Specification.

• Annex 2: An annotated API specification showing the exact differences relative to Java SE 10. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.

• Annex 3: Java SE 11 Editions of The Java Language Specification and The Java Virtual Machine Specification (PDFs). The Java SE 11 Editions contain all corrections and clarifications made since the Java SE 10 Editions, as well as additions for new features.

You should be aware of the content in that document as well as the items described in this page.

The descriptions on this Release Note page might also identify potential compatibility issues that you could encounter when migrating to JDK 11. The Kinds of Compatibility page on the OpenJDK wiki identifies three types of potential compatibility issues for Java programs used in these descriptions:

• Source: Source compatibility concerns translating Java source code into class files.

• Binary: Binary compatibility is defined in The Java Language Specification (PDF) as preserving the ability to link without error.

• Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.

See CSRs Approved for JDK 11 for the list of CSRs closed in JDK 11 and the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general information about compatibility.

Important Changes and Information

The following are some important changes in and information about this release. In some cases, additional details about the changes described below are provided in these Release Notes.

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

What's New in JDK 11 - New Features and Enhancements

The following notes describe some of the enhancements in Java SE 11 and JDK 11. The descriptions might include links to additional documentation that describes the enhancement in greater detail. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 11 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 11 and JDK 11 is the Java SE 11 (18.9) ( JSR 384) Platform Specification, which documents the changes to the specification made between Java SE 10 and Java SE 11. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 11.

core-libs/java.lang
➜ JEP 327 Unicode 10

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

core-libs/java.net
➜ JEP 321 HTTP Client (Standard)

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

core-libs/java.util:collections
➜ New Collection.toArray(IntFunction) Default Method

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.

core-libs/java.util:i18n
➜ Updated Locale Data to Unicode CLDR v33

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.

hotspot/compiler
➜ Lazy Allocation of Compiler Threads

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

hotspot/gc
➜ JEP 333 ZGC A Scalable Low-Latency Garbage Collector (Experimental)

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.

hotspot/gc
➜ JEP 318 Epsilon, A No-Op Garbage Collector

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.

hotspot/jvmti
➜ JEP 331 Low-Overhead Heap Profiling

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

hotspot/runtime
➜ JEP 181 Nest-Based Access Control

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.

security-libs
➜ JEP 324 Key Agreement with Curve25519 and Curve448

security-libs/javax.crypto
➜ Added Brainpool EC Support (RFC 5639)

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.

security-libs/javax.crypto
➜ JEP 329 ChaCha20 and Poly1305 Cryptographic Algorithms

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.

security-libs/javax.crypto
➜ 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.

security-libs/javax.crypto
➜ RSASSA-PSS Signature Support Added to SunMSCAPI

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

security-libs/javax.net.ssl
➜ JEP 332 Transport Layer Security (TLS) 1.3

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.

security-libs/org.ietf.jgss:krb5
Support for AES Encryption with HMAC-SHA2 for Kerberos 5 Defined in RFC 8009

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.

tools/javac
➜ JEP 323: Local-Variable Syntax for Lambda Parameters

The reserved type name var can now be used when declaring the formal parameters of a lambda expression ([JEP 323](http://openjdk.java.net/jeps/323)). 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.

tools/launcher
➜ JEP 330 Launch Single-File Source-Code Programs

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.

Removed Features and Options

This section describes the APIs, features, and options that were removed in Java SE 11 and JDK 11. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 11 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 11 and JDK 11 is the Java SE 11 (18.9) ( JSR 384) Platform Specification, which documents changes to the specification made between Java SE 10 and Java SE 11. This document includes the identification of removed APIs and features not described here. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 11. See CSRs Approved for JDK 11 for the list of CSRs closed in JDK 11.

client-libs
➜ Removal of com.sun.awt.AWTUtilities Class

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.

client-libs/2d
➜ Removal of Lucida Fonts from Oracle JDK

Oracle JDK no longer ships any fonts and relies entirely on fonts installed on the operating system.

This means that fonts in the Bigelow & Holmes Lucida family (Lucida Sans, Lucida Bright, and Lucida Typewriter) are no longer available to applications from the JDK.

If applications rely on fonts shipped in the JDK, they may need to be updated.

If system administrators are running Java server applications that rely on fonts shipped in the JDK rather than on system font packages, then the applications may fail to run until the system font packages are installed.

client-libs/java.awt
➜ Removal of appletviewer Launcher

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

client-libs/javax.imageio
➜ Oracle JDK's javax.imageio JPEG Plugin No Longer Supports Images with alpha

Previously, the Oracle JDK used proprietary extensions to the widely used IJG JPEG library in providing optional color space support. This was used to support PhotoYCC and images with an alpha component on both reading and writing. This optional support has been removed in Oracle JDK 11. Encountering encoded JPEG images in any of these formats is unlikely, unless they were previously encoded by an earlier version of the Oracle JDK. However, if they are encountered, decoding will now fail with an exception. Writing an image with an alpha channel will also fail with an exception. The most probable scenario for problems are applications which are unaware that they rely on this support. This could fail with an exception if the ImageWriter is called directly or if the Image I/O convenience methods are used. The write() method will now return false, meaning that it did not write the image.

A carefully written application should check for these scenarios, which will mitigate this. Note that the OpenJDK has never had this optional proprietary support. It has always failed and generated exceptions in these scenarios.

For detailed information about 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

core-libs
➜ Removal of sun.misc.Unsafe.defineClass

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-

core-libs/java.lang
➜ Removal of Thread.destroy() and Thread.stop(Throwable) Methods

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.

core-libs/java.nio
➜ Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck Property

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.

core-libs/java.util:i18n
➜ Removal of sun.locale.formatasdefault Property

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

core-svc/javax.management
➜ Removal of JVM-MANAGEMENT-MIB.mib

The specification for JVM monitoring and management through SNMP JVM-MANAGEMENT-MIB.mib has been removed. Customers can use JMX to monitor and manage a running JVM and to access the standard set of metrics and operations.

core-svc/tools
➜ Removal of SNMP Agent

The jdk.snmp module has been removed.

As a result, the following com.sun.management.snmp.* properties are no-op when set by using the -D option or 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

deploy
➜ Removal of Java Deployment Technologies

The Java Plugin and Java WebStart technologies that were deprecated in JDK 9 and marked as candidates for removal in JDK 10, have now been removed. Please note that the Java Control Panel, which was used for configuring the deployment technologies, has also been removed along with the shared system JRE (but not the server JRE) and the JRE Auto Update mechanism. More details are available in this white paper (PDF).

infrastructure
➜ Removal of JMC from the Oracle JDK

Java Mission Control (JMC) is no longer included in the JDK bundles. A stand-alone version of JMC, compatible with Oracle JDK 11 and OpenJDK 11, is available as a separate download.

javafx/other
➜ Removal of JavaFX from the Oracle JDK

The JavaFX modules have been removed from the JDK 11 release. These modules were included in earlier releases of the Oracle JDK, but not in the OpenJDK releases. The JavaFX modules will be available as a separate set of modules outside the JDK. More details are available in this white paper: http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf (PDF)

other-libs
➜ JEP 320 Remove the Java EE and CORBA Modules

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.

Deprecated Features and Options

This section describes the deprecated APIs, features, and options that have been identified as deprecated in this release and are subject to removal from future versions of Java SE and the JDK. They should be used with that possibility in mind. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 11 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications.

Other sources of information about the APIs, features, and options deprecated in Java SE 11 and JDK 11 include:

• Deprecated API page (API specification) - Identifies all deprecated APIs including those deprecated in Java SE 11.
• Java SE 11 (18.9) ( JSR 384) specification - Documents changes to the specification made between Java SE 10 and Java SE 11 that include the identification of deprecated APIs and features not described here.

You should be aware of the contents in those documents as well as the items described in this release notes page.

The descriptions of deprecated APIs might include references to the deprecation warnings of forRemoval=true and forRemoval=false. The forRemoval=true text indicates that a deprecated API might be removed from the next major release. The forRemoval=false text indicates that a deprecated API is not expected to be removed from the next major release but might be removed in some later release.

Note: JEP 277: Enhanced Deprecation provides a detailed description of the deprecation policy. You should be aware of the updated policy described in this document.

The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 11. See the JDK 11 Migration Guide for descriptions of specific compatibility issues. See CSRs Approved for JDK 11 for the list of CSRs closed in JDK 11.

core-libs/java.util.concurrent
➜ 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.

client-libs/javax.swing
➜ Deprecated NSWindowStyleMaskTexturedBackground

After an upgrade of the macOS SDK used to build the JDK, the behavior of the apple.awt.brushMetalLook and textured Swing properties has changed. When these properties are set, the title of the frame is still visible. It is recommended that the apple.awt.transparentTitleBar property be set to true to make the title of the frame invisible again. The apple.awt.fullWindowContent property can also be used.

Please note that Textured window support was implemented by using the NSTexturedBackgroundWindowMask value of NSWindowStyleMask. However, this was deprecated in macOS 10.12 along with NSWindowStyleMaskTexturedBackground, which was deprecated in macOS 10.14.

For additional information, refer to the following documentation:

• apple.awt.brushMetalLook: https://developer.apple.com/documentation/appkit/nstexturedbackgroundwindowmask?language=objc
• apple.awt.transparentTitleBar: https://developer.apple.com/documentation/appkit/nswindow/1419167-titlebarappearstransparent?language=objc
• apple.awt.fullWindowContent: https://developer.apple.com/documentation/appkit/nsfullsizecontentviewwindowmask

docs
➜ JEP 335 Deprecate the Nashorn JavaScript Engine

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

hotspot/compiler
➜ 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 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.

hotspot/runtime
➜ Obsolete Support for Commercial Features

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.

security-libs/org.ietf.jgss
➜ Deprecate Stream-Based GSSContext Methods

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.

tools
➜ JEP 336 Deprecate the Pack200 Tools and API

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.

Known Issues

The following notes describe known issues or limitations in this release.

Other Notes

The following notes describe additional changes and information about this release. In some cases, the following descriptions provide links to additional detailed information about an issue or a change.

client-libs/java.awt
➜ GTK3 Is Now the Default on Linux/Unix

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

core-libs/java.io:serialization
➜ 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.

core-libs/java.lang
➜ Method ClassgetAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present

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.

core-libs/java.lang
➜ Make Some System Properties Effectively readonly

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.

core-libs/java.lang
➜ 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.

core-libs/java.lang.invoke
➜ 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 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.

core-libs/java.lang.module
➜ Change to Policy for the Default Set of Modules Resolved When Compiling or Running Code on the Class Path

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.

core-libs/java.net
➜ URLClassLoader Does Not Specify Behavior When URL Array Contains null

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

core-libs/java.nio
➜ 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 was 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.

core-libs/java.nio
➜ SelectableChannel.register Can 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.

core-libs/java.nio
➜ 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. 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.

core-libs/java.nio
➜ 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. 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.

core-libs/java.util:i18n
➜ Japanese New Era Implementation

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"

docs
➜ Enable Java Access Bridge Check Box Option in Control Panel Is Not Available with JDK 11 Installer

The Java Access Bridge checkbox in the Windows Control Panel is not available in JDK11. This registration was part of the public JRE installation.

However, Java Access Bridge can still be enabled and disabled by following these steps:

1. Copy %JAVAHOME%\bin\windowsaccessbridge-64.dll to %WINDOWSHOME%\SYSTEM32. A reboot might be required after this step.
2. Run %JAVAHOME%\bin\jabswitch /enable and %JAVAHOME%\bin\jabswitch /disable.

Notes: %WINDOWSHOME% is the directory where Microsoft Windows is installed (for example, C:\WINDOWS) %JAVAHOME% is the directory where your JDK is installed (for example, C:\Program Files\Java\jdk-11)

hotspot/gc
➜ New PerfCounters for STW Phases on Concurrent GC Are Available

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.

hotspot/gc
➜ G1 Enables Adaptive Parallel Reference Processing by Default

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

hotspot/gc
➜ Fail Immediately If a GC That Is Unavailable Is Selected

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.

hotspot/gc
➜ 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.

hotspot/gc
➜ JVM Crash during G1 GC

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 the 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 it should not be unloaded.

hotspot/gc
➜ Better Stability with Older NUMA Libraries (-XX+UseNuma)

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.

hotspot/jvmti
➜ NotifyFramePop Request Is Not Cleared if JVMTI_EVENT_FRAME_POP Is Disabled

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.

hotspot/runtime
➜ Extend Class Data Sharing (CDS) to Support the Module Path

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.

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

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

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

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

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

hotspot/runtime
➜ JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording

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 

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

security-libs/java.security
➜ Added Google Trust Services GlobalSign Root Certificates

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

security-libs/java.security
➜ Added GoDaddy Root Certificates

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

security-libs/java.security
➜ Removal of Baltimore Cybertrust Code Signing CA

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

security-libs/java.security
➜ Removal of SECOM Root Certificate

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

security-libs/java.security
➜ Added T-Systems, GlobalSign and Starfield Services Root Certificates

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

security-libs/java.security
➜ Removal of AOL and Swisscom Root Certificates

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

security-libs/java.security
➜ Removal of Several Symantec Root CAs

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

security-libs/java.security
➜ Added Entrust Root Certificates

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

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

security-libs/javax.net.ssl
➜ BoringSSL Rejects JSSE TLS 1.3 HTTPS Connections When status_request Extension Is Disabled

BoringSSL is an SSL library deployed on some popular websites such as those run by Google/YouTube. An interoperability issue with the BoringSSL library can lead to a connection failure if TLSv1.3 is presented as the only enabled protocol in the ClientHello message and the certificate status_request extension is disabled. Enabling the certificate status_request extension by setting the jdk.tls.client.enableStatusRequestExtension system property to true will provide mitigation in such scenarios.

security-libs/javax.net.ssl
➜ TLS 1.3 Half-Close Policy

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.

security-libs/javax.net.ssl
➜ 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.

security-libs/javax.net.ssl
➜ supported_groups Extension Should Not be Present in ServerHello Handshake Message

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.

security-libs/javax.xml.crypto
➜ Updated xmldsig Implementation to Apache Santuario 2.1.1

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.

security-libs/javax.xml.crypto
➜ XML Signatures Signed with EC Keys Less Than 224 Bits Disabled

The secure validation mode of the XML Signature implementation has been enhanced to restrict EC keys less than 224 bits by default. The secure validation mode is enabled either by setting the property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty() method, or by running the code with a SecurityManager.

security-libs/org.ietf.jgss:krb5
➜ Kerberos Sequence Number Issues

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.

security-libs/org.ietf.jgss:krb5
➜ 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.

tools/javac
➜ --add-exports No Longer Implies Readability in 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.

tools/javac
Packages Not Visible in Imports Are Rejected

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.

tools/javac
➜ Missing Types Are Consistently Modeled as ERROR Types

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.

Differences between Oracle JDK and OpenJDK

Although we have stated the goal to have OpenJDK and Oracle JDK binaries be as close to each other as possible there remains, at least for JDK 11, several differences between the two options.

The current differences are:

• Only Oracle JDK offers Solaris, only OpenJDK offers Alpine Linux.
• Oracle JDK offers "installers" (msi, rpm, deb, etc.) which not only place the JDK binaries in your system but also contain update rules and in some cases handle some common configurations like set common environmental variables (such as, JAVA_HOME in Windows) and establish file associations (such as, use java to launch .jar files). OpenJDK is offered only as compressed archive (tar.gz or .zip).
• javac —release for release values 9 and 10 behave differently. Oracle JDK binaries include APIs that were not added to OpenJDK binaries like javafx, resource management, and (pre JDK 11 changes) JFR APIs.
• Usage Logging is only available in Oracle JDK.
• OpenJDK will (continue to) throw an error and halt if the -XX:+UnlockCommercialFeatures flag is used. Oracle JDK no longer requires the flag and will print a warning but continue execution if used.
• Oracle JDK requires that third party cryptographic providers be signed with an Oracle-provided certificate. OpenJDK will continue allowing the use of unsigned third party crypto providers.
• The output of java -version will be different. Oracle JDK will say java and include LTS. OpenJDK (when produced by Oracle) will say OpenJDK and not include the Oracle-specific LTS identifier.
• Oracle JDK will be released under OTN License. Any License file will need to point to OTN. OpenJDK will be released under GPLv2wCP and will include the GPL license.
• Oracle JDK will distribute FreeType under the FreeType license and OpenJDK will do so under GPLv2. The contents of \legal\java.desktop\freetype.md will therefore be different.
• Oracle JDK has Java cup and steam icons and OpenJDK has Duke icons.
• Oracle JDK source code includes "ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms." and OpenJDK source includes the GPL.