RELEASE NOTES: JDK 11

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

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.

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.

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, java.net.http.

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.

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.

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

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.

Removal of sun.locale.formatasdefault Property

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

Method Class::getAnnotation 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.

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.

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.

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.

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

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.

Removal of appletviewer Launcher

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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

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

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.

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

Added Support for PKCS#1 v2.2 Algorithms Including RSASSA-PSS Signature

The SunRsaSign and SunJCE providers have been enhanced with support for more algorithms defined in PKCS#1 v2.2, such as RSASSA-PSS signature and OAEP using FIPS 180-4 digest algorithms. New constructors and methods have been added to relevant JCA/JCE classes under the java.security.spec and javax.crypto.spec packages for supporting additional RSASSA-PSS parameters.

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

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

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.

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.

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.

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.

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). This builds on the ability in Java SE 10 to use var when declaring local variables.

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

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

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

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.

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 RSASSA-PSS family of SignatureMethod algorithms specified in RFC 6931.

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.

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.

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-

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

JEP 372: Remove the Nashorn JavaScript Engine

Summary

Remove the Nashorn JavaScript script engine and APIs, and the jjs tool. The engine, the APIs, and the tool were deprecated for removal in Java 11 with the express intent to remove them in a future release.

Motivation

The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 174 as a replacement for the Rhino scripting engine. When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.

With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.

Non-Goals

This removal does not affect, in any way, the javax.script API.

Description

Two JDK modules will be permanently removed:

• jdk.scripting.nashorn -- contains the jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages.

• jdk.scripting.nashorn.shell -- contains the jjs tool.

Risks and Assumptions

We assume that developers who rely on Nashorn have had enough notice of its proposed removal to make alternative arrangements. The deprecation-for-removal of Nashorn in JDK 11 was confirmed in June 2018, causing the proposed removal to be flagged at every use of the jdk.nashorn.* API and the jjs tool in JDK 11, 12, and 13. During this period, no set of credible developers expressed a clear desire to maintain Nashorn in JDK 14 and beyond.

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

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.

JEP 332: Transport Layer Security (TLS) 1.3

JDK 8u261 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: TLSAES128GCMSHA256, TLSAES256GCMSHA384

TLS 1.3 is disabled for default SSLContext("SSL" or "TLS") for client end-point.

The TLS 1.3 protocol can be enabled using several mechanisms already available in the JDK. For example, TLS 1.3 protocol can be enabled on SSL/TLS connections using SSLSocket/SSLEngine/SSLServerSocket APIs and system properties by the following:

1) sslSocket.setEnabledProtocols(new String[] { "TLSv1.3", "TLSv1.2"}); 2) Setting up and using a TLSv1.3 based SSLContext : SSLContext ctx = SSLContext.getInstance("TLSv1.3"); 3) Using the SSLParameters API: sslParameters.setProtocols(new String[] {"TLSv1.3", "TLSv1.2"}); 4) The jdk.tls.client.protocols system property can also be used to control the protocols in use for a TLS connection. One may launch their application with this property. For example, java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2" enables TLSv1.3 and TLSv1.2 on client SSLSockets. 5) The https.protocols system property can also be used to control the protocols on connection obtained through use of the HttpsURLConnection class or URL.openStream() operations. For example, -Dhttps.protocols=TLSv1.3,TLSv1.2.

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

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.

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 might be compatibility issues when upgrading to TLS 1.3. A new system property, jdk.tls.acknowledgeCloseNotify, is 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.
2. The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application can 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 that are no longer supported, it cannot 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; however, there could be a risk if an application depends on the handshake details of the TLS protocols.
6. The legacy com.sun.net.ssl.dhKeyExchangeFix system property has been removed from the new TLS implementation.

Improved JSSE debug logging format has been introduced to record the logger name, the logger level, the thread ID, the thread name, the time and the caller for each log item. Use the javax.net.debug=all system property to get full debug logs.

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: TLSAES128GCMSHA256, TLSAES256GCMSHA384 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 signaturealgorithmscert 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.

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 324: Key Agreement with Curve25519 and Curve448

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

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

RSASSA-PSS Signature Support Added to SunMSCAPI

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

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.

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.

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.

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.

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.

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.

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

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.

Description for Toolkit.getImage() and Toolkit.createImage()

The changes made under JDK-8033530 introduced an inconsistency between the implementation for and the documentation of the following methods:

• java.awt.Toolkit.getImage(URL u)
• java.awt.Toolkit.createimage(URL u)

The description in the API document should read:

This method first checks if there is a security manager installed. If so, the method calls the security managers checkPermission() method with the corresponding permission to ensure that the access to the image or the image creation is allowed. If the connection to the specified URL requires either URLPermission or SocketPermission, then URLPermission is used for security checks.

Restoring Previous `user.dir` Property Behaviour

A change, JDK-8194154, was introduced in the 8u342 release of OpenJDK, causing the JDK to ignore attempts to set the user.dir property. While this change is suitable for a major release (it was originally introduced in the initial release of OpenJDK 11), changing the behaviour of such a property in an update release creates compatibility issues in software that relies on the behaviour in prior versions of OpenJDK 8. As a result, we have reverted this change in 8u345.

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.

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

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.

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.

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 classes per its prior knowledge of unreachable classes. When these JNIHandles were later scanned, it lead to a crash.

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

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.

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.

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