RELEASE NOTES: JDK 20

Javac Warns about Type Casts in Compound Assignments with Possible Lossy Conversions

New lint option lossy-conversions has been added to javac to warn about type casts in compound assignments with possible lossy conversions. If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may occur.

The new warnings can be suppressed using @SuppressWarnings("lossy-conversions").

URL constructors called with malformed input may throw MalformedURLException for cases where it wasn't thrown previously

The parsing of input provided to the java.net.URL constructors has changed in this release to be more strict. If the URL constructors are called with malformed input then MalformedURLException may be thrown for cases where it wasn’t thrown previously.

In previous releases, some of the parsing/validation performed by the JDK built-in URLStreamHander implementations was delayed until URL::openConnection or URLConnection::connect was called. Some of these parsing/validation are now performed early, within URL constructors. An exception caused by a malformed URL that would have been delayed until the connection was opened or connected might now cause a MalformedURLException to be thrown at URL construction time.

This change only affects URL instances that delegate to JDK built in stream handler implementations. Only applications relying on JDK built-in stream handlers should be affected. Applications relying on custom third party URLStreamHandler implementations should remain unaffected.

A new JDK specific system property -Djdk.net.url.delayParsing or -Djdk.net.url.delayParsing=true can be specified on the command line to revert to the previous behavior. By default, the property is not set, and the new behavior is in place. The property can be specified on the java command line if unexpected regressions are observed.

This new property is provided for backward compatibility and may be removed in a future release.

GetLocalXXX/SetLocalXXX spec should require suspending target thread

The JVM TI spec of the GetLocalXXX/SetLocalXXX functions has been changed to require the target thread to be either suspended or the current thread. The error code JVMTIERRORTHREADNOTSUSPENDED will be returned if this requirement is not satisfied. The JVM TI agents which use the GetLocalXXX/SetLocalXXX API's need to be updated to suspend target thread if it is not the current thread. The full list of impacted JVM TI functions is: - GetLocalObject, GetLocalInt, GetLocalLong, GetLocalFloat, GetLocalDouble, GetLocalInstance, - SetLocalObject, SetLocalInt, SetLocalLong, SetLocalFloat, SetLocalDouble

Thread.suspend/resume changed to throw UnsupportedOperationException

The ability to suspend or resume a Thread with the Thread.suspend() and Thread.resume() methods has been removed in this release. The methods have been changed to throw UnsupportedOperationException. These methods were inherently deadlock prone and have been deprecated since JDK 1.2 (1998). The corresponding methods in ThreadGroup, to suspend or resume a group of threads, were changed to throw UnsupportedOperationException in Java 19.

java.lang.ThreadGroup Is degraded

Legacy java.lang.ThreadGroup has been degraded in this release. It is no longer possible to explicitly destroy a thread group. In its place, ThreadGroup is changed to no longer keep a strong reference to subgroups. A thread group is thus eligible to be GC'ed when there are no live threads in the group and nothing else is keeping the thread group alive.

The behavior of several methods, deprecated for removal in prior releases, are changed as follows:

• The destroy method does nothing.

• The isDestroyed method returns false.

• The setDaemon and isDaemon methods set/get a daemon status that is not used for anything.

• The suspend, resume, and stop methods throw UnsupportedOperationException.

For further details, see the JEP 425, section java.lang.ThreadGroup.

Thread.Stop changed to throw UnsupportedOperationException

The ability to "stop" a Thread with the Thread.stop() method has been removed in this release. The method has been changed to throw UnsupportedOperationException. Stopping a Thread by causing it to throw java.lang.ThreadDeath was inherently unsafe. The stop method has been deprecated since JDK 1.2 (1998). The corresponding method in ThreadGroup, to "stop" a group of threads, was changed to throw UnsupportedOperationException in Java 19.

As part of this change, java.lang.ThreadDeath has been deprecated, for removal.

New Implementation Note for LoginModule on Removing Null from a Principals or Credentials set

The Set implementation that holds principals and credentials in a JAAS Subject prohibits null elements and any attempt to add, query, or remove a null element will result in a NullPointerException. This is especially important when trying to remove principals or credentials from the subject at the logout phase but they are null because of a previous failed login. Various JDK LoginModule implementations have been fixed to avoid the exception. An Implementation Note has also been added to the logout() method of the LoginModule interface. Developers should verify and if necessary update any custom LoginModule implementations to be compliant with this implementation advice.

Update Timezone Data to 2022c

This version includes changes from 2022b that merged multiple regions that have the same timestamp data post-1970 into a single time zone data. All time zone IDs remain the same but the merged time zones will point to a shared zone data.

As a result, pre-1970 data may not be compatible with earlier JDK versions. The affected zones are Antarctica/Vostok, Asia/Brunei, Asia/KualaLumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake, Pacific/Wallis, Arctic/Longyearbyen, Atlantic/JanMayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.

For more details, refer to the announcement of 2022b

Grapheme support in BreakIterator

Character boundary analysis in java.text.BreakIterator now conforms to Extended Grapheme Clusters breaks defined in Unicode Consortium's Standard Annex #29. This change will introduce intentional behavioral changes because the old implementation simply breaks at the code point boundaries for the vast majority of characters. For example, this is a String that contains the US flag and a grapheme for a 4-member-family. ` "🇺🇸👨‍👩‍👧‍👦" This String will be broken into two graphemes with the new implementation: `` "🇺🇸", "👨‍👩‍👧‍👦" ` whereas the old implementation simply breaks at the code point boundaries: "🇺", "🇸", "👨", "(zwj)", "👩", "(zwj)", "👧", "(zwj)"‍, "👦" `` where (zwj) denotes ZERO WIDTH JOINER (U+200D).

InflaterInputStream.read Throws EOFException

A change to java.util.zip.InflaterInputStream in this release means it is possible that reading uncompressed bytes with this API can fail with an unexpected java.io.EOFException.

The issue arises when reading uncompressed bytes with a byte array that isn't large enough to fit all bytes that have been uncompressed. In that case, the additional uncompressed bytes are buffered by the implementation to be consumed by the next call to the read method. If the compressed stream is at end of stream then a subsequent read of the uncompressed data will fail incorrectly with EOFException.

This issue will be fixed in a future update. It may be possible to workaround the issue in some cases by calling read with a larger bye array.

Restore Behavior of java.math.BigDecimal.movePointLeft() and movePointRight() on a Zero Argument

When these methods are invoked with a zero argument on a target with a negative scale, they return a result which is numerically the same as the target, but with a different unscaled value and scale.

In earlier releases, they returned a result with the same unscaled value and scale, which was against the specification.

The behavior is unchanged when the target has a non-negative scale or when the argument is not zero.

G1 Remembered set memory footprint regression after JDK-8286115

JDK-8286115 changed ergonomic sizing of a component of the remembered sets in G1. This change causes increased native memory usage of the Hotspot VM for applications that create large remembered sets with the G1 collector.

In an internal benchmark total GC component native memory usage rose by almost 10% (from 1.2GB to 1.3GB).

This issue can be worked around by passing double the value of G1RemSetArrayOfCardsEntries as printed by running the application with -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions to your application.

E.g. pass -XX:+UnlockExperimentalVMOptions -XX:G1RemSetArrayOfCardsEntries=128 if a previous run showed a value of 64 for G1RemSetArrayOfCardsEntries in the output of -XX:+PrintFlagsFinal.

This issue has been addressed in JDK 19.0.1 or later.

G1: Disable preventive GCs by default

In JDK 17 G1 added "preventive" garbage collections (GCs): these are speculative garbage collections, with the goal of avoiding costly evacuation failures due to allocation bursts when the heap is almost full.

However, these (speculative) collections have the consequence of additional garbage collection work - as object aging is based on number of GCs with additional GCs cause premature promotion into the old generation - which leads to more data in the old generation, and more garbage collection work to remove these objects. This has been compounded by the current prediction to trigger preventive garbage collections being very conservative; which means these garbage collections are often triggered unnecessarily.

In the majority of cases this feature is a net loss, and as evacuation failures are now handled more quickly, there is no longer any reason for this feature and it has been disabled by default, it may be re-enabled by -XX:+UnlockDiagnosticVMOptions -XX:+G1UsePreventiveGC.