Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
The following sections are included in these Release Notes:
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.
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.
jlinkto create smaller custom runtimes.
.zip, which is more common in Windows OSs.
.dmg, which is more in line with the standard for macOS.
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.
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 include important additions for:
10 new scripts :
18 new blocks which include 10 blocks for the new scripts listed above and 8 blocks for the following existing scripts:
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 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,
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
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.
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:
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:
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
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:+UseCompressedClassPointers options are disabled by default. Enabling them will have no effect.
Class unloading is not supported. The
-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
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.
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:
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
getNestMembers methods of
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
ClassNotFoundException will be thrown.
JEP 324 Key Agreement with Curve25519 and Curve448JEP 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.
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.
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.
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
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.
RSASSA-PSS Signature Support Added to SunMSCAPI
The RSASSA-PSS signature algorithm support has been added to the SunMSCAPI provider.
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:
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:
The System properties,
jdk.tls.server.protocols, can be used to configure the default enabled protocols accordingly in the SunJSSE provider if needed.
Support for AES Encryption with HMAC-SHA2 for Kerberos 5 Defined in RFC 8009
The Kerberos 5 encryption types of
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_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.
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.
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 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.
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.
Removal of com.sun.awt.AWTUtilities Class
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.
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 adminstrators 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.
Removal of appletviewer Launcher
appletviewer tool was deprecated in JDK 9 (see JDK-8074165) and removed in this release.
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
Removal of sun.misc.Unsafe.defineClass
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:
Removal of Thread.destroy() and Thread.stop(Throwable) Methods
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.
Removal of sun.nio.ch.disableSystemWideOverlappingFileLockCheck 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.
Removal of sun.locale.formatasdefault Property
The system property
sun.locale.formatasdefault, introduced in JDK 7 for backwards compatibility, has been removed.
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.
Removal of SNMP Agent
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
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).
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.
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)
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.se.ee(Aggregator module for the six modules above)
jdk.xml.ws(Tools for JAX-WS)
jdk.xml.bind(Tools for JAXB)
The following JAX-WS tools, from the
jdk.xml.ws module, are removed:
The following JAXB tools, from the
jdk.xml.bind module, are removed:
The following CORBA tools, from the
java.corba module, are removed:
rmic compiler was updated to remove the
-iiop options. Consequently, the RMI compiler will no longer be able to generate IDL or IIOP stubs and tie classes.
In addition, the following system properties are no longer applicable due to the the removal of the Java EE and CORBA modules:
For more detailed information on the removal and possible replacement for the modules, refer to JEP 320.
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:
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 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.
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.
jjs shell tool have been deprecated and might be removed in a future release. Code that uses classes and interfaces from
jdk.nashorn.api.tree packages will get a deprecation warning from
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).
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.
Obsolete Support for Commercial Features
-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.
VM.check_commercial_features jcmd commands will also generate a warning message but have no additional effect.
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
verifyMIC methods that have an
InputStream argument. These methods have already been removed in RFC 8353.
JEP 336 Deprecate the Pack200 Tools and API
unpack200 tools, and the Pack200 API in
java.util.jar (JEP 336).
pack200 API and the tools associated with it,
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.
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.
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:
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.
Method ClassgetAnnotation Throws a TypeNotPresentException When the Annotation Class Is Not Present
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
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
Make Some System Properties Effectively readonly
The values of
user.name properties are cached at startup. Changes made using
System::setProperty after startup will not change the behavior of APIs in the
java.lang.ref.Reference Does Not Support Cloning
java.lang.ref.Reference::clone method always throws
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.
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.
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.
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.
Readiness Information Previously Recorded in SelectionKey Ready Set Not Preserved
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
selectNow) and doesn't process keys added to the selected-key set before performing another selection operation.
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
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.
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.
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.
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.
Separate Blocking and Non-blocking Code Paths
The implementations of
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:
SocketChannelthat is registered with a
Selectorwill now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a
ServerSocketChannelthat is registered with
Selectorwill 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
netstatto 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.
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.
Japanese New Era Implementation
Japanese calendars, both in
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:
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"
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:
%WINDOWSHOME%\SYSTEM32. A reboot might be required after this step.
%WINDOWSHOME% is the directory where Microsoft Windows is installed (for example,
%JAVAHOME% is the directory where your JDK is installed (for example,
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:
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
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).
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.
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.
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.
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.
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
||Disallowed (exits if specified)||Allowed (disables CDS)|
||Disallowed (exits if specified)||Allowed (disables CDS)|
||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 (
jdk.internal.vm.compiler). These are seldom upgraded in production software.
4As 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
--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
--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
--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.
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
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
The following types continue to be part of the
The change should be transparent to existing applications on the class path or module path.
Added Google Trust Services GlobalSign Root Certificates
The following root certificates have been added to the OpenJDK cacerts truststore:
DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Added GoDaddy Root Certificates
The following root certificates have been added to the OpenJDK cacerts truststore:
DN: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
DN: C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certification Authority
DN: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
DN: C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., CN=Starfield Root Certificate Authority - G2
Removal of Baltimore Cybertrust Code Signing CA
The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed:
DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Removal of SECOM Root Certificate
The following SECOM root certificate is no longer in use and has been removed:
DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP
Added T-Systems, GlobalSign and Starfield Services Root Certificates
The following root certificates have been added to the OpenJDK cacerts truststore:
DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
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
DN: CN=Starfield Services Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, ST=Arizona, C=US
DN: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE
DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
Removal of AOL and Swisscom Root Certificates
The following root certificates have been removed from the cacerts truststore:
DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US
DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US
DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
Removal of Several Symantec Root CAs
The following Symantec root certificates are no longer in use and have been removed:
DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
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
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
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
DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Added Entrust Root Certificates
The following root certificates have been added to the OpenJDK cacerts truststore:
DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2012 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - EC1
DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2
DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority
DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking
DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium
DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial
DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC
jarsigner Prints When a timestamp Will Expire
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.
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.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
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.
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.
supported_groups Extension Should Not be Present in ServerHello Handshake Message
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.
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:
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.
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
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.
KerberosString Uses UTF-8 Encoding by Default
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
false to encode
KerberosString as ASCII.
--add-exports No Longer Implies Readability in javac
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.
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.
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.
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:
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
.jarfiles). OpenJDK is offered only as compressed archive (
—releasefor 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.
-XX:+UnlockCommercialFeaturesflag is used. Oracle JDK no longer requires the flag and will print a warning but continue execution if used.
java -versionwill be different. Oracle JDK will say
javaand include LTS. OpenJDK (when produced by Oracle) will say OpenJDK and not include the Oracle-specific LTS identifier.
\legal\java.desktop\freetype.mdwill therefore be different.