OpenJDK

15.0.1

15.0.1

See all Versions

OpenJDK 16 Early Access

New Features:

• This section describes some of the enhancements in Java SE 15 and JDK 15. 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 15 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 15 and JDK 15 is the Java SE 15 ( JSR 390) Platform Specification, which documents the changes to the specification made between Java SE 14 and Java SE 15. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions also identify potential compatibility issues that you might encounter when migrating to JDK 15.
• Support for Unicode 13.0 (JDK-8239383)
• core-libs/java.lang
• This release upgrades Unicode support to 13.0, which includes the following:
• The java.lang.Character class supports Unicode Character Database of 13.0 level, which 13.0 adds 5,930 characters, for a total of 143,859 characters. These additions include 4 new scripts, for a total of 154 scripts, as well as 55 new emoji characters.
• The java.text.Bidi and java.text.Normalizer classes support 13.0 level of Unicode Standard Annexes, #9 and #15, respectively.
• The java.util.regex package supports Extended Grapheme Clusters based on 13.0 level of Unicode Standard Annex #29 For more detail about Unicode 13.0, refer to the Unicode Consortium's release note.
• Added isEmpty Default Method to CharSequence (JDK-8215401):
• java.lang.CharSequence has been updated in this release to define a default isEmpty method that tests if a character sequence is empty. Testing for, and filtering out, empty Strings and other CharSequences is a common occurrence in code and CharSequence::isEmpty can be used as a method reference. Classes that implement java.lang.CharSequence and another interface that defines isEmpty method should be aware of this addition as they may need to be modified to override the isEmpty method.
• JEP 371: Hidden Classes (JDK-8238358):
• JEP 371 introduces hidden classes in Java 15. Hidden classes have the following implications to existing code:
• Class::getName traditionally returns a binary name, but for a hidden class it returns a string that contains an ASCII forward slash (/) and is therefore not a binary name. Programs that assume the returned string is a binary name might need to be updated to handle hidden classes. That said, the longstanding practice of Unsafe::defineAnonymousClass was to define classes whose names were not binary names, so some programs may already handle such names successfully.
• Class::descriptorString and MethodType::descriptorString returns a string that contains a ASCII dot (.) for a hidden class and therefore is not a type descriptor conforming to JVMS 4.3. Programs that assume the returned string is a type descriptor that conforms to JVMS 4.3 might need to be updated to handle hidden classes.
• Class::getNestMembers is changed to not throw an exception when it fails to validate a nest membership of any member listed in NestMembers attribute. Instead, Class::getNestMembers returns the nest host and the members listed in the host's NestMembers attribute that are successfully resolved and determined to have the same nest host as this class. (This means it may return fewer members that listed in NestMembers attribute.) Existing code that expects LinkageError when there is a bad nest membership might be impacted.
• The nestmate test in the JVM is changed to throw only IllegalAccessError when the nest membership is invalid. Some historical understanding is necessary:
• In Java 8, every access control failure was signaled with IllegalAccessError (IAE). Moreover, if a given access check failed with IAE once, then the same check would fail with IAE every time.
• In Java 11, the introduction of nest mates (JEP 181) meant that an access control failure could be signaled either with IllegalAccessError or, if nest membership was invalid, LinkageError. Still, if a given access check failed with a specific exception, then the same check would always fail with the same exception.
• In Java 15, the introduction of Lookup::defineHiddenClass implies that the nest host of the lookup class must be determined eagerly, when the hidden class is defined as a nestmate of the lookup class. Both Lookup::defineHiddenClass and Class::getNestHost both determine the nest host of a class in a more resilient manner than the JVM did in Java 11; namely, the API simply treats a class as self-hosted if its purported nest membership is invalid. For consistency with the API, the JVM no longer throws LinkageError when a class's nest membership is invalid, and instead treats the class as self-hosted. This means that the JVM only throws IAE from access control (because a self-hosted class will not permit any other class to access its private members). This is the behavior expected by the vast majority of user code.
• JVM TI GetClassSignature returns a string that contains a ASCII dot (.) for a hidden class. JVM TI agents might need updating for hidden classes if they assume the returned string from GetClassSignature is a type descriptor conforming to JVMS 4.3.
• Added Support for SO_INCOMING_NAPI_ID Support (JDK-8243099):
• A new JDK-specific socket option SO_INCOMING_NAPI_ID has been added to jdk.net.ExtendedSocketOptions in this release. The socket option is Linux specific and allows applications to query the NAPI (New API) ID of the underlying device queue associated with its socket connection and take advantage of the Application Device Queue (ADQ) feature of high performance Network Interface Card (NIC) devices.
• Specialized Implementations of TreeMap Methods (JDK-8176894):
• The TreeMap class now provides overriding implementations of the putIfAbsent, computeIfAbsent, computeIfPresent, compute, and merge methods. The new implementations provide a performance improvement. However, if the function provided to the compute- or merge methods modifies the map, ConcurrentModificationException may be thrown, because the function that is provided to these methods is prohibited from modifying the map. If a ConcurrentModificationException occurs, the function must either be changed to avoid modifying the map, or the surrounding code should be rewritten to replace uses of the compute- and merge methods with conventional Map methods such as get and put.
• See JDK-8227666 for further information.
• Added Ability to Configure Third Port for Remote JMX (JDK-8234484):
• JMX supports (explicit) remote network access through the configuration of two network ports (either from the command line or in a property file), by setting the following properties:
• com.sun.management.jmxremote.port=
• com.sun.management.jmxremote.rmi.port=
• Note: If it is not specified, the second port will default to the first.
• A third local port is also opened to accept (local) JMX connections. This port previously had its number selected at random, which could cause port collisions.
• However, it is now possible to configure the third JMX port (local only) by using:
• com.sun.management.jmxremote.local.port=
• New Option Added to jstatd for Specifying RMI Connector Port Number (JDK-8196729):
• A new -r option has been added to the jstatd command to specify the RMI connector port number. If a port number is not specified, a random available port is used.
• New Option Added to jcmd for Writing a gzipped Heap Dump (JDK-8237354):
• A new integer option gz has been added to the GC.heap_dump diagnostic command. If it is specified, it will enable the gzip compression of the written heap dump. The supplied value is the compression level. It can range from 1 (fastest) to 9 (slowest, but best compression). The recommended level is 1.
• New Options Added to jhsdb for debugd Mode (JDK-8196751):
• Three new options have been added to the jhsdb command for the debugd mode:
• --rmiport is used to specify a RMI connector port number. If a port number is not specified, a random available port is used.
• --registryport is used to specify a RMI registry port number. This option overrides the system property sun.jvm.hotspot.rmi.port. If a port number is not specified, the system property is used. If the system property is not set, the default port 1099 is used.
• --hostname is used to specify a RMI connector host name. The value could be a hostname or an IPv4/IPv6 address. This option overrides the system property java.rmi.server.hostname. If a host name not specified, the system property is used. If the system property is not set, a system host name is used.
• Added Revocation Checking to jarsigner (JDK-8242060):
• A new -revCheck option has been added to the jarsigner command to enable revocation checking of certificates.
• Tools Warn If Weak Algorithms Are Used Before Restricting Them (JDK-8172404):
• The keytool and jarsigner tools have been updated to warn users about weak cryptographic algorithms being used before they are disabled. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys.
• SunJCE Provider Supports SHA-3 Based Hmac Algorithms (JDK-8172680):
• The SunJCE provider has been enhanced to support HmacSHA3-224, HmacSHA3-256, HmacSHA3-384, and HmacSHA3-512. Implementations for these algorithms are available under the Mac and KeyGenerator services. The Mac service generates the keyed-hash and the KeyGenerator service generates the key for the Mac.
• New System Properties to Configure the TLS Signature Schemes (JDK-8242141):
• Two new system properties have been added to customize the TLS signature schemes in JDK. jdk.tls.client.SignatureSchemes has been added for the TLS client side, and jdk.tls.server.SignatureSchemes has been added for the server side.
• Each system property contains a comma-separated list of supported signature scheme names specifying the signature schemes that could be used for the TLS connections.
• The names are described in the "Signature Schemes" section of the Java Security Standard Algorithm Names Specification.
• Support for certificate_authorities Extension (JDK-8206925):
• The "certificate_authorities" extension is an optional extension introduced in TLS 1.3. It is used to indicate the certificate authorities (CAs) that an endpoint supports and should be used by the receiving endpoint to guide certificate selection.
• With this JDK release, the "certificate_authorities" extension is supported for TLS 1.3 in both the client and the server sides. This extension is always present for client certificate selection, while it is optional for server certificate selection.
• Applications can enable this extension for server certificate selection by setting the jdk.tls.client.enableCAExtension system property to true. The default value of the property is false.
• Note that if the client trusts more CAs than the size limit of the extension (less than 2^16 bytes), the extension is not enabled. Also, some server implementations do not allow handshake messages to exceed 2^14 bytes. Consequently, there may be interoperability issues when jdk.tls.client.enableCAExtension is set to true and the client trusts more CAs than the server implementation limit.
• Support for canonicalize in krb5.conf (JDK-8239385):
• The 'canonicalize' flag in the krb5.conf file is now supported by the JDK Kerberos implementation. When set to true, RFC 6806 name canonicalization is requested by clients in TGT requests to KDC services (AS protocol). Otherwise, and by default, it is not requested.
• The new default behavior is different from JDK 14 and previous releases where name canonicalization was always requested by clients in TGT requests to KDC services (provided that support for RFC 6806 was not explicitly disabled with the sun.security.krb5.disableReferrals system or security properties).
• JEP 378: Text Blocks (JDK-8236934):
• Text blocks have been added to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over the format when desired.
• Removed Features and Options:
• This section describes the APIs, features, and options that were removed in Java SE 15 and JDK 15. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 15 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 15 and JDK 15 is the Java SE 15 ( JSR 390) Platform Specification, which documents changes to the specification made between Java SE 14 and Java SE 15. 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 15. See CSRs Approved for JDK 15 for the list of CSRs closed in JDK 15.
• Removal of Terminally Deprecated Solaris-specific SO_FLOW_SLA Socket Option (JDK-8244582):
• In this release, in conjunction with the removal of the Solaris port in JEP 381, the JDK-specific socket option jdk.net.ExtendedSocketOptions.SO_FLOW_SLA, which is only relevant to sockets on Solaris, and its supporting classes SocketFlow and SocketFlow.Status, have been removed.
• Removal of RMI Static Stub Compiler (rmic) (JDK-8225319):
• The RMI static stub compiler rmic has been removed. The rmic tool is obsolete and has been deprecated for removal since JDK 13.
• Removal of Nashorn JavaScript Engine (JDK-8236933):
• The Nashorn JavaScript script engine, its APIs, and the jjs tool have been removed. 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.
• Removal of Deprecated Constant RMIConnectorServer.CREDENTIAL_TYPES (JDK-8213222):
• The terminally deprecated constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE has been removed. A filter pattern can be specified instead by using RMIConnectorServer.CREDENTIALS_FILTER_PATTERN.
• Obsolete -XX:UseAdaptiveGCBoundary (JDK-8228991):
• The VM option UseAdaptiveGCBoundary is obsolete. Use of this option will produce an obsolete option warning but will otherwise be ignored.
• This option was previously disabled by default, and enabling it only had an effect when also using -XX:+UseParallelGC. Enabling it was intended to provide a performance benefit for some applications. However, it has been disabled by default for a long time because of crashes and performance regressions.
• Removal of DocuSign Root CA Certificate (JDK-8225068):
• The following expired DocuSign root CA certificate has been removed from the cacerts keystore:
• + alias name "keynectisrootca [jdk]"
• Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR
• Removal of Comodo Root CA Certificate (JDK-8225069):
• The following expired Comodo root CA certificate has been removed from the cacerts keystore:
• + alias name "addtrustclass1ca [jdk]"
• Distinguished Name: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE
• Removal of com.sun.net.ssl.internal.ssl.Provider Name (JDK-8219989):
• The legacy SunJSSE provider name, "com.sun.net.ssl.internal.ssl.Provider" has been removed and should no longer be used. The "SunJSSE" name should be used instead. For example, SSLContext.getInstance("TLS", "SunJSSE").
• Retired the Deprecated SSLSession.getPeerCertificateChain() Method Implementation (JDK-8241039):
• The implementation of the deprecated SSLSession.getPeerCertificateChain() method has been removed from the JDK in the SunJSSE provider and the HTTP client implementation. The default implementation of this method has been changed to throw UnsupportedOperationException.
• SSLSession.getPeerCertificateChain() is a deprecated method and will be removed in a future release. To mitigate the removal compatibility impact, applications should use the SSLSession.getPeerCertificates() method instead. For service providers, please remove this method from the existing implementation, and do not support this method in any new implementation.
• Deprecated Features and Options:
• Additional sources of information about the APIs, features, and options deprecated in Java SE 15 and JDK 15 include:
• The Deprecated API page identifies all deprecated APIs including those deprecated in Java SE 15.
• The Java SE 15 ( JSR 390) specification specification documents changes to the specification made between Java SE 14 and Java SE 15 that include the identification of deprecated APIs and features not described here.
• JEP 277: Enhanced Deprecation provides a detailed description of the deprecation policy. You should be aware of the updated policy described in this document.
• You should be aware of the contents in those documents as well as the items described in this release notes page.
• The descriptions of deprecated APIs might include references to the deprecation warnings of forRemoval=true and forRemoval=false. The forRemoval=true text indicates that a deprecated API might be removed from the next major release. The forRemoval=false text indicates that a deprecated API is not expected to be removed from the next major release but might be removed in some later release.
• The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 15. See CSRs Approved for JDK 15 for the list of CSRs closed in JDK 15.
• Deprecated NSWindowStyleMaskTexturedBackground (JDK-8240995):
• After an upgrade of the macOS SDK used to build the JDK, the behavior of the apple.awt.brushMetalLook and textured Swing properties has changed. When these properties are set, the title of the frame is still visible. It is recommended that the apple.awt.transparentTitleBar property be set to true to make the title of the frame invisible again. The apple.awt.fullWindowContent property can also be used.
• Please note that Textured window support was implemented by using the NSTexturedBackgroundWindowMask value of NSWindowStyleMask. However, this was deprecated in macOS 10.12 along with NSWindowStyleMaskTexturedBackground, which was deprecated in macOS 10.14.
• For additional information, refer to the following documentation:
• apple.awt.brushMetalLook: https://developer.apple.com/documentation/appkit/nstexturedbackgroundwindowmask?language=objc
• apple.awt.transparentTitleBar: https://developer.apple.com/documentation/appkit/nswindow/1419167-titlebarappearstransparent?language=objc
• apple.awt.fullWindowContent: https://developer.apple.com/documentation/appkit/nsfullsizecontentviewwindowmask
• Deprecated RMI Activation for Removal (JDK-8245068):
• The RMI Activation mechanism has been deprecated and may be removed in a future version of the platform. RMI Activation is an obsolete part of RMI that has been optional since Java 8. It allows RMI server JVMs to be started ("activated") upon receipt of a request from a client, instead of requiring RMI server JVMs to be running continuously. Other parts of RMI are not deprecated. See JEP 385 for further information.
• Deprecated -XX:ForceNUMA Option (JDK-8243628):
• The VM option ForceNUMA is deprecated. Use of this option will produce a deprecation warning. This option will be removed in a future release.
• This option has always been disabled by default. It exists to support testing of NUMA-related code paths when running on a single node / UMA platform.
• Disabled Biased-locking and Deprecated Biased-locking Flags (JDK-8231264):
• Biased locking has been disabled by default in this release. In addition, the VM option UseBiasedLocking along with the VM options BiasedLockingStartupDelay, BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold, BiasedLockingDecayTime and UseOptoBiasInlining have been deprecated. The options will continue to work as intended but will generate a deprecation warning when they are used.
• Biased locking might affect performance on applications that exhibit significant amounts of uncontended synchronization, such as applications that rely on older Java Collections APIs that synchronize on every access. Hashtable and Vector are examples of these APIs. Use -XX:+BiasedLocking on the command line to re-enable biased locking. Report any significant performance regressions to Oracle with biased locking disabled.
• Disable Native SunEC Implementation by Default (JDK-8237219):
• The SunEC crypto provider no longer advertises curves that are not implemented by using modern formulas and techniques. Arbitrary and named curves, listed at the bottom of this note, are disabled. Commonly used named curves, secp256r1, secp384r1, secp521r1, x25519, and x448, remain supported and enabled by SunEC because they use modern techniques. Applications that still require the disabled curves from the SunEC provider can re-enable them by setting the System property jdk.sunec.disableNative to false. For example: java -Djdk.sunec.disableNative=false ....
• If this property is set to any other value, the curves will remain disabled. Exceptions thrown when the curves are disabled will contain the message Legacy SunEC curve disabled, followed by the name of the curve. Methods affected by the change are KeyPair.generateKeyPair(), KeyAgreement.generateSecret(), Signature.verify(), and Signature.sign(). These methods throw the same exception class they had before when the curve was not supported.
• The following curves are disabled: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
• Added forRemoval=true to Previously Deprecated ContentSigner APIs (JDK-8242260)
• security-libs/jdk.security
• The ContentSigner and ContentSignerParameters classes in the com.sun.jarsigner package support alternative signers and have been deprecated with forRemoval=true. When the -altsigner or -altsignerpath options are specified, the jarsigner tool produces a warning that these options are deprecated and will be removed.