JDK 15 Early-Access Release Notes

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

Build 29

Enable ShowCodeDetailsInExceptionMessages by default (JDK-8233014)

hotspot/runtime

The default of the flag ShowCodeDetailsInExceptionMessages was changed to 'true'. The helpful NullPointerException messages of JEP 358 are now printed by default. The messages contain snippets of the code where the NullPointerException was raised.

App deployers should double check the output of their web applications and similar usage scenarios. The NullPointerException message could be included in application error messages or be displayed by other means in the app. This could give remote attackers valuable hints about a potential vulnerable state of the software components being used.

An example message is 'Cannot read field "c" because "a.b" is null'. The attacker knows that field b of a contains null which might be unintended and offer an opportunity for an attack. For more details of what the message can contain see above mentioned JEP 358.

Build 27

Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option (JDK-8244582)

core-libs/java.net

In this release, in conjunction with the removal of the Solaris port in JEP381 (JDK-8241787 ), 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.

Build 25

Support the certificate_authorities extension (JDK-8206925)

security-libs/javax.net.ssl

The "certificate_authorities" extension is an optional extension introduced in TLS 1.3 and used to indicate the certificate authorities (CAs) which an endpoint supports and which should be used by the receiving endpoint to guide certificate selection.

With this update, the certificate_authorities extension is supported for TLS 1.3 in both client and server sides in the JDK. 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 System Property, "jdk.tls.client.enableCAExtension" to "true". The default value of the property is "false".

Note that if the client trusts more CAs such that it exceeds 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. Thus, there may be interoperability issues if "jdk.tls.client.enableCAExtension" is set to "true" and the client trusts more CAs such that it exceeds the server implementation limit.

Support for CLDR version 37 (JDK-8239480)

core-libs/java.util:i18n

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 37. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes:

Build 24

Flags controlling C1 inlining has new names (JDK-8235673)

hotspot/compiler

A number of flags controlling inlining in the C1 and C2 compilers has been split up into separate flags. The C2 compiler keeps the flags with the old names, and the C1 compiler gets new flags.

Old flags now only controlling C2

  • MaxInlineLevel
  • MaxRecursiveInlineLevel
  • MaxInlineSize
  • MaxTrivialSize
  • InlineSmallCode
  • FreqInlineSize

New flags for C1 replacing the old ones

  • C1MaxInlineLevel
  • C1MaxRecursiveInlineLevel
  • C1MaxInlineSize
  • C1MaxTrivialSize

Deprecation

If the old flags are used in a JDK build without the C2 compiler, an deprecation warning will be printed.

Support for Unicode 13.0 (JDK-8239383)

core-libs/java.lang

This release upgrades Unicode support to 13.0 which includes the following:

  • java.lang.Character supports Unicode Character Database of 13.0 level, in 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.
  • java.text.Bidi and java.text.Normalizer classes support 13.0 level of Unicode Standard Annexes, #9 and #15, respectively.
  • 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.

Biased-locking has been disabled by default and is deprecated (JDK-8231264)

hotspot/runtime

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 in this release. The options will continue to work as intended but will generate a deprecation warning when used.

Biased locking may affect performance on applications that exhibit significant amounts of uncontended synchronization, for example, those that rely on the older Java Collections APIs which synchronize on every access, like Hashtable or Vector. Use -XX:+BiasedLocking on the command line to re-enable biased locking. Report any significant performance regressions to Oracle with biased locking disabled.

Build 23

localizedBy() should override localized values with default values (JDK-8244245)

core-libs/java.time

java.time.format.DateTimeFormatter.localizedBy(Locale) method now honors the default locale values, such as Chronologyand/or DecimalStyle of the specified locale argument. For example, with the prior JDK:

jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
    .localizedBy(Locale.forLanguageTag("fa"))
    .format(LocalDate.now())
$3 ==> "جمعه 1 مهٔ 2020"

The numbers are in Arabic (Western) numerals, whereas with JDK 15:

jshell> DateTimeFormatter.ofLocalizedDate(FormatStyle.FULL)
    .localizedBy(Locale.forLanguageTag("fa"))
    .format(LocalDate.now())
$3 ==> "جمعه ۱ مهٔ ۲۰۲۰"

The numbers are Extended Arabic-Indic numerals because it is the default numbering system for the Farsi locale.

Add revocation checking to jarsigner (JDK-8242060)

security-libs/java.security

A new -revCheck option has been added to jarsigner to enable revocation checking of certificates.

Build 22

Deprecate -XX:ForceNUMA option (JDK-8243628)

hotspot/gc

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, and exists to support testing of NUMA-related code paths when running on a single node / UMA platform.

Removal of Comodo Root CA Certificate (JDK-8225069)

security-libs/java.security

The following expired Comodo root CA certificate was 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 DocuSign Root CA Certificate (JDK-8225068)

security-libs/java.security

The following expired DocuSign root CA certificate was removed from the cacerts keystore:

  • alias name "keynectisrootca [jdk]"

    Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR

Build 20

Lookup::defineClass should link the class (JDK-8238195)

core-libs/java.lang.invoke

Lookup::defineClass is specified to throw LinkageError if a linkage error occurs. The implementation is fixed in this release to link the class before returned conforming to the specification. If Lookup::defineClass is called to define a class that fails linking, LinkageError will be thrown.

Tools should warn if weak algorithms are used before restricting them (JDK-8172404)

security-libs/java.security

The keytool and jarsigner tools have been updated to warn users about weak cryptographic algorithms before they are disabled. In this update, the tools will emit warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys.

DatagramPacket.getPort() now returns 0 when the port is not set. (JDK-8237890)

core-libs/java.net

In this release, the default port number for a datagram packet has been changed to 0. Previously, this value was -1, which was undocumented. The port can be retrieved by DatagramPacket::getPort.

JEP 371: Hidden Classes (JDK-8238358)

core-libs/java.lang.invoke

JEP 371 introduces hidden classes in Java 15. Hidden classes have the following implications to existing code:

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

  2. 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 may need to be updated to handle hidden classes.

  3. 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 plus 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 if there is a bad nest membership may be impacted.

  4. 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 ever 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.
  1. JVM TI GetClassSignature returns a string that contains a ASCII dot (.) for a hidden class. JVM TI agents may need updating for hidden classes if they assume the returned string from GetClassSignature is a type descriptor conforming to JVMS 4.3.

Obsolete -XX:UseAdaptiveGCBoundary (JDK-8228991)

hotspot/gc

The VM option UseAdaptiveGCBoundary is obsolete. Use of this option will produce an obsolete option warning and will be otherwise ignored.

This option was previously disabled by default, and enabling it only had an effect when also using -XX:+UseParallelGC. Enabling it was supposed to provide some performance benefit for some applications. However, it has been disabled by default for a long time, due to crashes and performance regressions; it is unclear that it ever worked properly.

Add forRemoval=true to already deprecated ContentSigner APIs (JDK-8242260)

security-libs/jdk.security

The ContentSigner and ContentSignerParameters classes in the com.sun.jarsigner package support alternative signers and are now deprecated with forRemoval=true. The jarsigner tool will also emit a warning that the options are deprecated and will be removed when the -altsigner or -altsignerpath option is specified.

New System Properties to Configure the TLS Signature Schemes (JDK-8242141)

security-libs/javax.net.ssl

Two new System Properties are added to customize the TLS signature schemes in JDK. jdk.tls.client.SignatureSchemes is added for TLS client side, and jdk.tls.server.SignatureSchemes is added for 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.

Build 19

Default SSLEngine Should Create in Server Role (JDK-8237474)

security-libs/javax.net.ssl

In JDK 11 and later, javax.net.ssl.SSLEngine by default used client mode when handshaking. As a result, the set of default enabled protocols may differ to what is expected. SSLEngine would usually be used in server mode. From this JDK release onwards, SSLEngine will default to server mode. The javax.net.ssl.SSLEngine.setUseClientMode​(boolean mode) method may be used to configure the mode.

The java.net.HttpClient does not override the protocols specified in the SSLContext default parameters (JDK-8239594)

core-libs/java.net

In this release during the setup of new connections java.net.http.HttpClient now uses the default set of protocols provided by the SSLContext during the negotiation of the TLS handshake. The HttpClient has been updated to no longer override any default selected protocols in the SSLContext, in the absence of any SSLParameters explicitly supplied to the HttpClient.builder. As a result, the actual TLS version negotiated may differ from that of previous releases, or may even succeed or fail to negotiate where it previously may not have. See JDK-8239594 for more details.

SunJCE provider now supports SHA-3 based Hmac algorithms (JDK-8172680)

security-libs/javax.crypto

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 is for generating the keyed-hash and the KeyGenerator service is for generating the key for the Mac.

Build 18

Remove RMI Static Stub Compiler (rmic) (JDK-8225319)

core-libs/java.rmi

The RMI static stub compiler rmic is removed. The rmic tool is obsolete and has been deprecated for removal since JDK 13.

Improved Ergonomics for G1 Heap Region Size (JDK-8241670)

hotspot/gc

The default heap region size calculation changed to return larger regions by default. The calculation still aims to have 2048 regions, but two aspects have changed:

  • Only the maximum heap size is considered. The old calculation also took the initial heap size into consideration, but this can give unexpected behavior when no heap size is set.
  • The region size is rounded up to the nearest power of 2 instead of down. This will return larger region sizes in cases where the maximum heap size is not a power of 2.

These changes improve startup and runtime performance.

Build 16

Disable native SunEC implementation by default (JDK-8237219)

security-libs/javax.crypto

The SunEC crypto provider no longer advertises curves that are not implemented 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 as 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 as they had before if the curve was not supported.

The following are the disabled curves: 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

Retire the deprecated SSLSession.getPeerCertificateChain() method (JDK-8241039)

security-libs/javax.net.ssl

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.

Retire the com.sun.net.ssl.internal.ssl.Provider name (JDK-8219989)

security-libs/javax.net.ssl

The legacy SunJSSE provider name, "com.sun.net.ssl.internal.ssl.Provider" has been removed and should not be used anymore. The "SunJSSE" name should be used instead (for example, "SSLContext.getInstance("TLS", "SunJSSE")").

Build 15

Case insensitive matching doesn't work correctly for some character classes (JDK-8214245)

core-libs/java.util.regex

Java regular expression engine supports the case insensitive mode. When this mode is turned on, the engine is supposed to match the input text without regard to the case of the characters it consists of.

However, the current implementation of matching against some named character classes (those that are encoded with p{name} or P{name} constructs) fail to respect the case insensitive mode.

The fix will make these character classes to behave consistently with respect to the case sensitivity. When the regular expression engine operates in the case insensitive mode, the named character classes will match the input characters without regard to their case: lower case, upper case or title case.

Build 13

Allow SunPKCS11 initialization with NSS when external FIPS modules are present in the Security Modules Database (JDK-8238555)

security-libs/javax.crypto:pkcs11

The SunPKCS11 security provider can now be initialized with NSS when FIPS-enabled external modules are configured in the Security Modules Database (NSSDB). Prior to this change, the SunPKCS11 provider would throw a RuntimeException with the message: "FIPS flag set for non-internal module" when such a library was configured for NSS in non-FIPS mode.

This change allows the JDK to work properly with recent NSS releases in GNU/Linux operating systems when the system-wide FIPS policy is turned on.

Further information can be found in JDK-8238555.

Build 12

ValueRange.of(long, long, long) does not throw IAE on invalid inputs (JDK-8239520)

core-libs/java.time

java.time.temporal.ValueRange.of() methods are now correctly throwing an InvalidArgumentException on given invalid arguments. For example, of(5, 2, 10) which is invalid because the minimum is greater than the smallest maximum, now throws the exception.

Build 10

Field layout computation overhaul (JDK-8237767)

hotspot/runtime

The way field layout is computed has been changed, with more aggressive optimizations to avoid unused gaps in instances. It is possible to disable these new optimizations with a new VM option -XX:-UseEmptySlotsInSupers.

For a limited time, it is still possible to continue to use the old code to compute field layout with a new VM option -XX:-UseNewFieldLayout. This option is already deprecated in JDK 15 and the old code will be removed in JDK 16.

Localized time zone name inconsistency between English and other locales (JDK-8236548)

core-libs/java.util:i18n

English time zone names provided by the CLDR locale provider are now correctly synthesized following the CLDR spec, rather than substituted from the COMPAT provider. For example, SHORT style names are no longer synthesized abbreviations of LONG style names but produce GMT offset formats.

Build 8

DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException (JDK-8235783)

core-libs/java.net

Previously, DatagramChannel::disconnect threw an IOException while DatagramSocket::disconnect did not. As a result, the DatagramChannel::socket adaptor, which calls DatagramChannel::disconnect, catches the thrown IOException and rethrows it as an Error. However, this was undocumented behavior and not user-friendly.

DatagramChannel::socket adapter has now been changed to throw an UncheckedIOException and the specification of DatagramSocket::disconnect has been updated to document that an implementation may now throw an UncheckedIOException. This ensures consistency in behavior between DatagramSocket, DatagramChannel and DatagramChannel::socket adaptor.

Build 7

The java.awt.Robot.delay() method completes with the interrupt status set when interrupted (JDK-8210231)

client-libs/java.awt

The implementation of the java.awt.Robot.delay() method was changed to complete with the interrupt status set when interrupted.

If a thread is interrupted while waiting in the java.awt.Robot.delay() method, then this method will return immediately with the interrupt status set. If the interrupted status is already set, this method returns immediately with the interrupt status set.

Build 6

Remove deprecated constant RMIConnectorServer.CREDENTIAL_TYPES (JDK-8213222)

core-svc/javax.management

The terminally deprecated constant javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE has been removed. A filter pattern can be specified instead using RMIConnectorServer.CREDENTIALS_FILTER_PATTERN.

Build 5

Support monetary grouping separator in DecimalFormat/DecimalFormatSymbols (JDK-8227313)

core-libs/java.text

DecimalFormat/DecimalFormatSymbols classes are now capable of dealing with grouping separators for currency values. For example, the monetary grouping separator for German in Austria is '.' whereas normal grouping separator is ' '.

Not Yet Integrated

NSWindowStyleMaskTexturedBackground deprecated (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:

MS950 charset encoder's conversion table is modified (JDK-8233385)

core-libs/java.nio.charsets

Some of the one-way byte-to-char mappings are now aligned with the preferred mappings provided by [Unicode Consortium] (https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt).

Delivered

Remove the Nashorn JavaScript Engine (JDK-8236933)

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.

JEP 378: Text Blocks (JDK-8236934)

Add text blocks 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.

JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) (JDK-8209683)

hotspot/gc

The Z Garbage Collector (ZGC) is now ready for use in production and no longer marked as an experimental feature. ZGC is enabled by the -XX:+UseZGC command-line option (also using -XX:+UnlockExperimentalVMOptions is no longer needed).

See JEP 377 for more details.