Starting with the July 2023 CPU, on operating systems where ASLR (Address Space Layout Randomization) is enabled, the CDS archive will be placed at a random address picked by the operating system.

This change may have a minor performance impact: (a) Start-up time may increase because the JVM needs to patch pointers inside the CDS archive; (b) Memory usage may increase because the memory used by the CDS archive is no longer shareable across processes. We expect the impact to be small because such increases should be only a small fraction of the overall application usage.

In the unlikely event that you must disable ASLR for CDS, you can use the JVM flags -XX:+UnlockDiagnosticVMOptions -XX:ArchiveRelocationMode=0. The usage of such flags is not recommended.

The China National Standard body (CESI) has recently published GB18030-2022. This is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The purpose of this enhancement is to incorporate 35 code points (U+9FCD - U+9FEF) from Unicode 11.0 into Java SE 8 to allow implementations to comply with their Implementation Level 1 requirements.

The China National Standard body (CESI) has recently published GB18030-2022, which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The Charset implementation for this new standard has now replaced the prior 2000 standard. However, this new standard has some incompatible changes from the prior implementation. For those who need to use the old mappings, a new system property, jdk.charset.GB18030, is introduced. By setting its value to 2000, the previous JDK releases' mappings for the GB18030 Charset are used, which are based on the 2000 standard.

The China National Standard body (CESI) has recently published GB18030-2022. This is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The purpose of this enhancement is to incorporate 108 code points from CJK Unified Ideographs Extension E block from Unicode 11.0 into Java SE 8 to allow implementations to comply with their Implementation Level 2 requirements.

RSA private and public keys in PKCS#1 format can now be accepted by JDK providers, such as the RSA KeyFactory.impl from the SunRsaSign provider. The RSA private or public key object should have the PKCS#1 format and an encoding matching the ASN.1 syntax for a PKCS#1 RSA private key and public key.

Installing into the same, shared jdk-(family) directory is the default behavior for the JDK starting with the July 2023 CPU. It could lead to FilesInUse issues if JDK files are locked by the "System User". We recommend shutting down any apps using the JDK as the "System User" before upgrading.

There is the possibility of an application crash with the following error:

# Internal Error (g1CollectedHeap.cpp:5923), pid=xxxxx, tid=xxxxxx
# guarantee(!dcqs.completed_buffers_exist_dirty()) failed: must be

This affects JDK 8u371 and JDK 8u381 runtimes using G1 GC on all supported platforms.

The failure is now corrected in the JDK 8u381 b32 Bundle Patch Release available via My Oracle Support.

Upgrading from an 8u361 (or earlier) 32-bit JRE to an 8u371 (or later) 32-bit JRE when an 8u371 (or later) 64-bit JRE is already installed will cause the java.exe command to not be found. For example:

1. Install 32-bit 8u361
2. Install 64-bit 8u371 (or later)
3. Install 32-bit 8u371 (or later)

java.exe will now not work from all places. It will only work directly from the bin directory.

java.exe will not work unless you specify the full path to the bin directory of your JRE.

There are 2 workarounds:

• Workaround 1: uninstall and reinstall the latest version of 64-bit 8u371 (or later)
• Workaround 2: specify the full path to java.exe in the \bin directory of the JRE, for example: C:\Program Files\Java\jre-1.8\bin\java.exe

JDK 8u381 includes several enhancements and fixes to improve the cgroup v1 and v2 support for containers. The improvements include accurately detecting the resource limits of containers, correctly reporting the collected container metrics, printing additional container information, and improving application stability in containerized environments.

Some of the notable stability enhancements are:

JDK-8292083: Java applications may experience out-of-memory errors and run the risk of being killed by the OOM killer when running in a containerized environment where the container is configured with a higher memory limit than the available physical memory on the host system. JDK 8u381 addresses this stability issue. In the previous release, this situation can be avoided by using either -XX:-UseContainerSupport, or -XX:MaxRAM=<physical memory>, or by setting a memory limit for your container that is lower than the physical memory.

JDK-8286030: This release addresses an issue where Java applications may encounter a fatal error when the same /tmp directory is shared across multiple containers. In earlier releases, this crash can be avoided by mounting /tmp to different locations for different containers. Alternatively, the '-XX:-UsePerfData' JVM option can be used to prevent JVMs running within different containers from writing performance data to the shared /tmp folder and thus avoid this issue.

Added an "Obsoletes" tag to JDK 8 RPM packages to allow automatic upgrades from older JDK 8 RPM packages.

• jdk-1.8 package obsoletes jdk1.8 package.
• jre-1.8 package obsoletes jre1.8 package.
• jdk-1.8-headful package obsoletes jdk1.8 package.
• jre-1.8-headful package obsoletes jre1.8 package.

No "Obsoletes" tag was added to the jdk-1.8-headless package to prevent upgrading from the full to headless JDK.

The changes allow automatic upgrades for JDK 8 RPM packages starting from the 8u151 update when jdk1.8 and jre1.8 package names were first introduced. Older JDK 8 updates will not be eligible for automatic upgrades to 8u381 and newer updates.

Due to the limitations of "Obsoletes" tag downgrades from 8u381 to older versions are not supported.

A regression where the /usr/java/default symlink is not created by RPM installers on Linux platforms has been fixed. Installers will create the /usr/java/default symlink if it doesn't exist, targeting the /usr/java/latest symlink.

The JDK RPM installer will remove incorrectly constructed entries of "java" and "javac" groups registered by older Oracle JDK RPM installers from the alternatives before registering new "java" and "javac" entries.

An incorrectly constructed entry of the "java" group contains commands that are supposed to belong to the "javac" group.

An incorrectly constructed entry of the "javac" group contains commands that are supposed to belong to the "java" group.

All incorrectly constructed entries belonging to Oracle JDK RPM packages will be removed from the alternatives to avoid corruption of the alternatives internal data.

The removal has a potential side effect for users who have installed multiple JDK versions that are not updated to the latest release. Commands from a removed "java" or "javac" group are now unavailable for system Java switch, which potentially changes the current system Java without a warning. For example, if there is an out-of-date JDK RPM from an 11+ release, say 11.0.17, with an incorrectly constructed single "java" group installed and 8u381 RPM with this patch is installed, it will remove an entry from the "java" group belonging to the 11.0.17 RPM and thus will switch the current system Java from 11.0.17 to 8u381. The side effect will only happen when you install a lower JDK family with the fix, such as 8u381, and there is an out-of-date JDK from a higher family, such as 11.0.17, installed on the system. In that case, 8u381 will replace the older 11.0.17 as the latest. The remedy for the user is to install the latest JDK 11.

The following root certificate has been added to the cacerts truststore:

+ TWCA

  + twcaglobalrootca
    DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW

The following root certificates have been added to the cacerts truststore:

+ Google Trust Services LLC

 + gtsrootcar1
  DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootcar2
  DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar3
  DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar4
  DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US

The following root certificates have been added to the cacerts truststore:

+ Microsoft Corporation

  + microsoftecc2017
    DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US

+ Microsoft Corporation
  + microsoftrsa2017
    DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US

This JDK implements Maintenance Release 5 of the Java SE 8 specification (JSR 337). This is indicated by the system property java.specification.maintenance.version having the value of "5".

Starting with the July 2023 CPU, on operating systems where ASLR (Address Space Layout Randomization) is enabled, the CDS archive will be placed at a random address picked by the operating system.

This change may have a minor performance impact: (a) Start-up time may increase because the JVM needs to patch pointers inside the CDS archive; (b) Memory usage may increase because the memory used by the CDS archive is no longer shareable across processes. We expect the impact to be small because such increases should be only a small fraction of the overall application usage.

In the unlikely event that you must disable ASLR for CDS, you can use the JVM flags -XX:+UnlockDiagnosticVMOptions -XX:ArchiveRelocationMode=0. The usage of such flags is not recommended.

A behavioral change has been made when the default conf/security/java.security security configuration file fails to load. In such a scenario, the JDK will now throw an InternalError.

Such a scenario should never occur. The default security file should always be present. Prior to this change, a static security configuration was loaded.

A new system property, jdk.jar.maxSignatureFileSize, has been added to allow applications to control the maximum size of signature files in a signed JAR. The value of the system property is the desired size in bytes. The default value is 8000000 bytes.

A native GSS-API library named sspi_bridge.dll has been added to the JDK on the Windows platform. The library is client-side only and uses the default credentials. It will be loaded when the sun.security.jgss.native system property is set to "true". A user can still load a third-party native GSS-API library by setting the sun.security.jgss.lib system property to its path.

Native GSS automatically uses cached credentials from operating systems, thus the javax.security.auth.useSubjectCredsOnly system property should be set to false.

com.sun.security.auth.module.Krb5LoginModule does not call native JGSS. Avoid using com.sun.security.auth.module.Krb5LoginModule from JAAS config.

The AppleScript engine implementing the javax.script engine API has been removed without replacement. The AppleScript engine has worked inconsistently. The services configuration (META-INF/services) file was missing and only worked by accident when installing JDK 7 or JDK 8 on systems that had Apple's version of AppleScriptEngine.jar already on the system.

The com.apple.concurrent.Dispatch API was a Mac-only API. It was carried into JDK 7u4 with the port of Apple's JDK 6 code. Developers are encouraged to use the standard java.util.concurrent.Executor and java.util.concurrent.ExecutorService APIs instead.

This issue prevents yum from automatically installing the correct packages required by Oracle Linux specific x86_64 headless and headful JDK packages. Instead of x86_64 packages, it will install i686 packages. To workaround the issue, you may manually install packages with the same names as indicated by yum but with the x86_64 architecture.

After you have the x86_64 headless and/or headful jdk packages installed, you can get the list of required x86_64 packages by running the following script:

rpm -qa | grep -E -e '^jdk-.*-headful-.*\.x86_64$' -e '^jdk-.*-headless-.*\.x86_64$' | xargs -r rpm -q --requires | sort -u | cut -d ' ' -f 1 | grep -v '^rpmlib' | xargs -r rpm -q --whatprovides | sort -u | grep -e '.i[3456]86$' | xargs -r rpm -q --queryformat '%{name}.x86_64\n' | xargs -r echo

It will output a space-separated list of names of required x86_64 packages to stdout. You can pass this list to a sudo yum install command to ensure the installation of the required packages.

Fixed a regression where the /usr/java/default symlink is not created by RPM installers on Linux platforms. Now, installers will create the /usr/java/default symlink if it doesn't exist, targeting the /usr/java/latest symlink.

After upgrading to JDK 8u371 or later, there is the possibility of an application crash. The error log has a stack trace that starts with the following:

# Internal Error (g1CollectedHeap.cpp:5923), pid=xxxxx, tid=xxxxxx
# guarantee(!dcqs.completed_buffers_exist_dirty()) failed: must be

The above error may impact applications using G1 GC on all supported platforms.

Those who encounter the above error are encouraged to create a Service Request through My Oracle Support so that we can provide an interim solution to resolve the error.

Some Swing components, such as JLabels and JButtons, which display application text, will try to interpret that text as HTML, principally to enable styled text. The HTML processing of the text for these components will no longer recognize the <object> tag which allows for subclasses of java.awt.Component to be rendered on the component. To re-enable this, applications must specify -Dswing.html.object=true.

The installation directory name of the Oracle JRE in an RPM package has changed from /usr/java/jre-1.8.0_${UPDATE}-${ARCH} to /usr/lib/jvm/jre-1.8-oracle-${ARCH}. The installation directory name of the Oracle JDK in an RPM package has changed from /usr/java/jdk-1.8.0_${UPDATE}-${ARCH} to /usr/lib/jvm/jdk-1.8-oracle-${ARCH}. Thus the 8u371 and 8u381 releases of JDK for x64 will both be installed in the /usr/lib/jvm/jdk-1.8-oracle-x64 directory and the JRE for x64 will both be installed in the /usr/lib/jvm/jre-1.8-oracle-x64 directory. Both JDK and JRE RPM packages will create /usr/java/jdk-1.8.0-${ARCH} and /usr/java/jre-1.8.0-${ARCH} links respectively pointing to the installation directories for backward compatibility.

For the x86_64 platform, the value of the ${ARCH} suffix has changed from amd64 to x64. For the x86_32 platform, the value of the ${ARCH} has changed from i586 to x86.

The JRE RPM package name has changed from jre1.8 to jre-1.8 to make it consistent with other release families. To prevent confusion between the old and new naming patterns, the new package cannot be upgraded using a single "rpm -i ..." or "rpm -U ..." command. Please uninstall the old JRE and then install the new JRE. For example, sudo rpm -e jre1.8; sudo rpm -i jre-8u371-linux-x64.rpm. The JDK RPM package name has changed from jdk1.8 to jdk-1.8 to make it consistent with other release families. To prevent confusion between the old and new naming patterns, the new package cannot be upgraded using a single "rpm -i ..." or "rpm -U ..." command. Please uninstall the old JDK and then install the new JDK. For example, sudo rpm -e jdk1.8; sudo rpm -i jdk-8u371-linux-x64.rpm.

Communication with the alternatives framework for the JDK RPM package has changed. JDK RPM packages of prior versions registered a single java group of commands with the alternatives framework. The JDK 1.8 RPM package registers java and javac groups with the alternatives framework. The java group is for commands used to run applications: java, javaws, jcontrol, jjs, keytool, orbd, pack200, policytool, rmic, rmid, rmiregistry, servertool, tnameserv, unpack200. The javac group is used for all other commands. The set of commands registered by the package has not changed.

Three new Oracle Linux (OL)-specific JDK RPM packages have been added: jdk-1.8-headless, jdk-1.8-headful, and jre-1.8-headful. These packages are available in OL7, OL8, and OL9 repositories. They are not available for download from oracle.com.

• jdk-1.8-headless is a Headless Java Runtime for running non-GUI applications.
• jdk-1.8-headful is a Headful Java Runtime with Development Tools for developing and running applications of all types.
• jre-1.8-headful is a Headful Java Runtime for running applications of all types.

The combination of the OL-specific jdk-1.8-headless and jdk-1.8-headful packages provides the same JDK image and the same capabilities as the jdk-1.8 oracle.com package. The jre-1.8-headful package provides the same JRE image and the same capabilities as the jre-1.8 oracle.com package. OL-specific JDK and JRE RPM packages specify required capabilities, and the "Release" property of these packages has a %{dist} suffix. The value of the Release property of all RPM packages contains the value of the build number instead of the milestone.

Windows JDK installers must install the Oracle JDK in %Program Files%\Java\jdk-%FEATURE% instead of %Program Files%\Java\jdk-%VNUM%. That is, all updates of the same release must share one installation directory. It will not be possible to install older versions of a family if there is a newer JRE of that family already installed.

Thus the JDK 8u371 and JDK 8u381 releases will both install into %Program Files%\Java\jdk-1.8 by default, and they both cannot be installed at the same time.

Note: The Java 8u371 feature JDK-8293762 will now only allow one JRE of each family to be installed at one time. The REMOVEOLDERJRES=1 feature will no longer be supported with the standalone MSI. This is by design, as we only allow one JRE of each family of Java. The newer JREs will auto-upgrade older JREs of the same family.

The Oracle JDK installation directory name will be changed from /Library/Java/JavaVirtualMachines/jdk1.8.0_${UPDATE}.jdk to /Library/Java/JavaVirtualMachines/jdk-1.8.jdk. Thus the 8u371 and 8u381 releases will both install into the /Library/Java/JavaVirtualMachines/jdk-1.8.jdk installation directory. Installing an older JDK update release will log an error, and not install the JDK, if a newer version of the same feature release already exists. An error dialog will be shown except in the case of a silent installation. JDK 8 update releases shipped prior to this release, JDK 8u371, will not be uninstalled during installation of JDK 8u371 or later.

The following root certificate has been added to the cacerts truststore:

+ Certigna (Dhimyotis)
   + certignaca
      DN: CN=Certigna, O=Dhimyotis, C=FR

SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.

If a client or server still needs to use the SSLv3 protocol they can do so by enabling it through the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs.

After updating to JDK 8u361, applications failed to start, with multiple Exceptions being thrown, ultimately identified by a java.lang.ArrayIndexOutOfBoundsException occurring at jdk.internal.platform.cgroupv2.CgroupV2Subsystem.initSubsystem.

The JVM sometimes failed to initialize on Linux systems where /proc/self/mountinfo does not contain any mounted filesystem or controllers for cgroup.

For background information, see also My Oracle Support see KM Doc ID 2923131.1.

As part of ongoing maintenance, the JDK for Windows is built using the Microsoft Visual Studio 2022 toolchain starting with this release.

If you have issues with a Java application and if you have native or JNI libraries that are compiled with a different release of the compiler, then you must consider compatibility issues between the runtimes. Specifically, your environment is supported only if you follow the Microsoft guidelines when dealing with multiple runtimes. More information can be found in “C++ binary compatibility between Visual Studio versions”.

Applications using the Dell BSAFE Crypto-J 3rd party security provider may encounter an IOException if decoding DH or DSA algorithm parameters with the following exception:

Exception in thread "main" java.io.IOException: Could not decode parameters. at com.rsa.cryptoj.o.ms.engineInit(Unknown Source) at java.security.AlgorithmParameters.init(AlgorithmParameters.java:293)

Dell BSAFE Crypto-J version 6.2.6.2 has been released to address this issue. Applications using this provider should upgrade to that version or later. For applications on older versions of this provider, an interoperability fix has been added to this release of the JDK.

Upgrading from an 8u361 (or earlier) 32-bit JRE to an 8u371 (or later) 32-bit JRE when an 8u371 (or later) 64-bit JRE is already installed will cause the java.exe command to not be found. For example:

1. Install 32-bit 8u361
2. Install 64-bit 8u371 (or later)
3. Install 32-bit 8u371 (or later)

java.exe will now not work from all places. It will only work directly from the bin directory.

java.exe will not work unless you specify the full path to the bin directory of your JRE.

There are 2 workarounds:

• Workaround 1: uninstall and reinstall the latest version of 64-bit 8u371 (or later)
• Workaround 2: specify the full path to java.exe in the \bin directory of the JRE, for example: C:\Program Files\Java\jre-1.8\bin\java.exe

The JVM will fail to initialize on Linux systems where /proc/self/mountinfo does not contain any mounted filesystem or controllers for cgroups. This failure occurs due to faulty detection logic where it incorrectly detects a cgroup v1 system, having no mounted controllers, as a cgroup v2 system.

A fix is available via the 8u361 b32 BPR available on My Oracle Support (see KM Doc ID 2923131.1).

• Palestine transitions are now Saturdays at 02:00.
• Simplify three Ukraine zones into one.
• Jordan and Syria switch from +02/+03 with DST to year-round +03.
• Mexico will no longer observe DST except near the US border.
• Chihuahua moves to year-round -06 on 2022-10-30.
• Fiji no longer observes DST.
• Move links to 'backward'.
• In vanguard form, GMT is now a Zone and Etc/GMT a link.
• zic now supports links to links, and vanguard form uses this.
• Simplify four Ontario zones.
• Fix a Y2438 bug when reading TZif data.
• Enable 64-bit time_t on 32-bit glibc platforms.
• Omit large-file support when no longer needed.
• In C code, use some C23 features if available.
• Remove no-longer-needed workaround for Qt bug 53071.

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u361) be used after the next critical patch update scheduled for April 18, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u361) on 2023-05-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

An OCSP response signed with the RSASSA-PSS algorithm is now supported.

After updating to JDK 8u361, applications may fail to start, with multiple Exceptions being thrown, ultimately identified by a java.lang.ArrayIndexOutOfBoundsException occurring at jdk.internal.platform.cgroupv2.CgroupV2Subsystem.initSubsystem.

The JVM will fail to initialize on Linux systems where /proc/self/mountinfo does not contain any mounted filesystem or controllers for cgroups. This failure occurs due to faulty detection logic where it incorrectly detects a cgroup v1 system, having no mounted controllers, as a cgroup v2 system.

A fix is available via the 8u361 b32 BPR available on My Oracle Support (see KM Doc ID 2923131.1).

Previous JDK releases used an incorrect interpretation of the Linux cgroups parameter "cpu.shares". This might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources when the JVM is used inside a container.

Starting from this JDK release, by default, the JVM no longer considers "cpu.shares" when deciding the number of threads to be used by the various thread pools. The -XX:+UseContainerCpuShares command-line option can be used to revert to the previous behavior. This option is deprecated and may be removed in a future JDK release.

The “JavaScript script engine” for FXML is now disabled by default. Any .fxml file that has a "javascript" Processing Instruction (PI) will no longer load by default, and an exception will be thrown.

It can be enabled by setting the system property: -Djavafx.allowjs=true

ProcessBuilder on Windows is restored to address a regression caused by JDK-8250568. Previously, an argument to ProcessBuilder that started with a double-quote and ended with a backslash followed by a double-quote was passed to a command incorrectly and may cause the command to fail. For example the argument "C:\\Program Files\", would be seen by the command with extra double-quotes. This update restores the long standing behavior that does not treat the backslash before the final double-quote specially.

Two system properties have been added which control the keep alive behavior of HttpURLConnection in the case where the server does not specify a keep alive time. Two properties are defined for controlling connections to servers and proxies separately. They are http.keepAlive.time.server and http.keepAlive.time.proxy respectively. More information about them can be found in Networking Properties.

This version of the JDK no longer includes a copy of Java VisualVM. VisualVM is now available as a separate download from https://visualvm.github.io.

The readObject method of _DynAnyFactoryStub has been amended, such that, when reading the stringified IOR from serialized data, it will, by default, accept stringified IORs in IOR: URI format, only. As DynAnyFactory is a locally or ORB constrained type, it is not useful that serialized data should contain corbaname or corbaloc URIs. Furthermore, an ORB will prohibit the binding of a name in the INS to a DynAnyFactory IOR, as such, using a corbaname to reference an instance of DynAnyFactory is not meaningful.

A system property is introduced, org.omg.DynamicAny.DynAnyFactoryStub.disableIORCheck, which when set to true, will revert the _DynAnyFactoryStub::readObject to its current behavior and bypass the additional IOR checks.

Enterprise Performance Pack supports JDK Flight Recorder (JFR).

JFR is a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM in production. Recorded data can be opened in JDK Mission Control (JMC). To start recordings from within JMC, a new version of JMC is required. Currently, it is not released as part of the JDK but is available as a downloadable patch from Supported Java SE Downloads on MOS or from JDK Mission Control 8 Downloads. JFR comes with a supported API to produce and consume data programmatically.

Relevant Changes for JFR include JEP 328: Flight Recorder, JEP 349: JFR Event Streaming

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u351) be used after the next critical patch update scheduled for January 17, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u351) on 2023-02-17. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.

The new SHA-256 based MAC algorithms were introduced in the 11.0.12, 8u301, and 7u311 JDK versions. Keystores created using this newer, stronger, MAC algorithm cannot be opened in JDK versions earlier than 11.0.12, 8u301, and 7u311. A 'java.security.NoSuchAlgorithmException' exception will be thrown in such circumstances.

For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.

On platforms that support the concept of a thread name on their native threads, the java.lang.Thread.setName() method will also set that native thread name. However, this will only occur when called by the current thread, and only for threads started through the java.lang.Thread class (not for native threads that have attached via JNI). The presence of a native thread name can be useful for debugging and monitoring purposes. Some platforms may limit the native thread name to a length much shorter than that used by the java.lang.Thread, which may result in some threads having the same native name.

The Java Access Bridge checkbox in the Windows Control Panel is not available in JDK11. This registration was part of the public JRE installation.

However, Java Access Bridge can still be enabled and disabled by following these steps:

1. Copy %JAVAHOME%\bin\windowsaccessbridge-64.dll to %WINDOWSHOME%\SYSTEM32. A reboot might be required after this step.
2. Run %JAVAHOME%\bin\jabswitch /enable and %JAVAHOME%\bin\jabswitch /disable.

Note: %WINDOWSHOME% is the directory where Microsoft Windows is installed (for example, C:\WINDOWS) %JAVAHOME% is the directory where your JDK is installed (for example, C:\Program Files\Java\jdk-11)

JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers.

To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to this policy:

• Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.

This exception may be removed in a future JDK release. To determine if your signed JARs are affected by this change, run jarsigner -verify -verbose -certs on the signed JAR, and look for instances of "SHA1" or "SHA-1" and "disabled" and a warning that the JAR will be treated as unsigned in the output.

For example:

-  Signed by "CN="Signer""

     Digest algorithm: SHA-1 (disabled)
     Signature algorithm: SHA1withRSA (disabled), 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms.

Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or override it by using the java.security.properties system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.

The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.

This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.

An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC'ed earlier - previously the referent is kept alive until PhantomReference objects are GC'ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.

java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and get() method will return null in JDK 9.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid memory leak because its referent is no longer referenced. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, NullPointerException may be thrown. Such code will need to be updated.

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.

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/Kuala_Lumpur, 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/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.

For more details, refer to the announcement of 2022b.

This JDK implements Maintenance Release 4 of the Java SE 8 specification (JSR 337). Implementing this maintenance release is indicated by the new system property java.specification.maintenance.version having the value of "4".

A new system property named jdk.httpserver.maxConnections has been introduced to allow users to configure the com.sun.net.httpserver.HttpServer to limit the maximum number of open connections to the server at any given time. This system property takes an integer value and can be configured to be a positive integer. If the property is absent, set to 0, or a negative value, the server will not limit the number of open connections. By default, this system property is not set.

A new Class Hierarchy Analysis implementation is introduced in the HotSpot JVM. It features enhanced handling of abstract and default methods which improves inlining decisions made by the JIT-compilers. The new implementation supersedes the original one and is turned on by default.

To help diagnose possible issues related to the new implementation, the original implementation can be turned on by specifying the -XX:+UnlockDiagnosticVMOptions -XX:-UseVtableBasedCHA command-line flags.

The original implementation may be removed in a future release.

This enhancement causes phantom references to be automatically cleared by the garbage collector just as soft and weak references are.

An object becomes phantom reachable after it has been finalized. This change may cause phantom reachable objects to be garbage collected earlier. Previously, the referent was kept alive until the associated PhantomReference objects were collected or cleared by the application. This behavioral change should only impact existing code that depends on a PhantomReference being enqueued rather than when the referent is freed from the heap.

The java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and the get() method will return null in Enterprise Performance Pack and later releases.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid a memory leak because its referent is no longer referenced. In other words, the get method is not expected to be called in common cases once the enqueue method has been called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, a NullPointerException may be thrown. Such code will need to be updated.

The java.lang.ref.Reference::clone method always throws a CloneNotSupportedException. Therefore, Reference objects cannot be meaningfully cloned. To copy a Reference object, call the constructor to create a new Reference object with the same referent and reference queue instead.

In Java SE Subscription Enterprise Performance Pack, constant pool patching of classes created by calling the unsupported sun.misc.Unsafe.defineAnonymousClass method is not enabled and could cause your application to crash. The cpPatches argument to defineAnonymousClass should be null.

In Java SE Subscription Enterprise Performance Pack, the methods monitorEnter, monitorExit, and tryMonitorEnter have been removed from the unsupported sun.misc.Unsafe class. These methods are not used within the JDK itself and are very rarely used outside of the JDK.

The Java SE 8 Enterprise Performance Pack follows the versioning format defined by JEP 322, and reports the actual VM version of 17.x, when, for example, java -version is invoked. However, for compatibility purposes, the sun.misc.Version methods jvmMajorVersion() and jvmMinorVersion() instead report the same VM version as Java SE 8 i.e. 25.x. This ensures that application code checking for a Java 8 runtime by looking for a major version greater than, or equal to, 25, will work correctly even though the actual VM version is 17.

Some linux kernel versions (including, but not limited to 3.13.0-121-generic and 4.4.0-81-generic) are known to contain an incorrect fix for a linux kernel stack overflow issue (See CVE-2017-1000364). The incorrect fix can trigger crashes in the Java Virtual Machine. Upgrading the kernel to a version that includes the corrected fix addresses the problem.

This change enforces the unqualified name format checks for NameAndType strings as outlined in the JVM specification sections 4.4.6 and 4.2.2, meaning that some illegal names and descriptors that users may be utilizing in their classfiles will now be caught with a Class Format Error. This includes format checking for all strings under non-referenced NameAndType's. Users will see a change if they (A) are using Java classfile version 6 or below and have an illegal NameAndType descriptor with no Methodref or Fieldref reference to it; or (B) are using any Java classfile version and have an illegal NameAndType name with no Methodref or Fieldref reference to it.

In both (A) and (B) the users will now receive a ClassFormatError for those illegal strings, which is an enforcement of unqualified name formats as delineated in JVMS 4.2.2.

When dumping the heap in binary format, HPROF format 1.0.2 is always used now. Previously, format 1.0.1 was used for heaps smaller than 2GB. HPROF format 1.0.2 is also used by jhsdb jmap for the serviceability agent.

When running with compressed references on x86_64, one of the CPU registers holds the heap base pointer to be used for references encoding/decoding. This register is not available for register allocation.

Simple implementations before this release made this register unavailable (and thus unused) even if compressed references were disabled. In this release, the implementation was revised to put this unused register back into the available registers pool. Configurations with large heaps and/or -XX:-UseCompressedOops benefit from this improvement.

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.

For improved performance, JVM/TI ObjectFree events are no longer posted within GC pauses. The events are still posted as requested, and will be posted before ObjectFree events are enabled or disabled with SetNotificationMode. SetNotificationMode can be used to explicitly flush ObjectFree events, if needed.

The default value for BiasedLockingStartupDelay has been changed to 0. The flag BiasedLockingStartupDelay previously had the default value 4000 which delayed the use of biased locking with 4 s (4000 ms). The reason for this delay was performance but recent performance runs show no difference between the 4000 ms delay and no delay. Since having the delay will cause other parts of the VM to do extra work, having the default set to 0 makes more sense.

The JNI function DetachCurrentThread has been added to the list of JNI functions that can safely be called with an exception pending. The HotSpot Virtual Machine has always supported this as it reports that the exception occurred in a similar manner to the default handling of uncaught exceptions at the Java level. Other implementations are not obligated to do anything with the pending exception.

The -XX:-JNIDetachReleasesMonitors flag requested that the VM run in a pre-JDK 6 compatibility mode with regard to not releasing monitors when a JNI attached thread detaches. This option is obsolete in JDK 9, and is ignored, as the VM always conforms to the JNI Specification and releases monitors. Use of this option will result in a warning being issued in JDK 9 and it may be removed completely in a future release.

When synchronization is performed on an object, an association is established between the object and the object monitor that implements the synchronization. In the past, the reference from a monitor to its associated object was a strong reference. These strong references would be observable through JVM TI functions that walk the heap (reported as JVMTI_HEAP_ROOT_MONITOR or JVMTI_HEAP_REFERENCE_MONITOR) and in heap dumps (reported as HPROF_GC_ROOT_MONITOR_USED). As of this release, a weak reference is used. These are not observable to JVM TI or heap dumps. Consequently, JVMTI_HEAP_ROOT_MONITOR, JVMTI_HEAP_REFERENCE_MONITOR and HPROF_GC_ROOT_MONITOR_USED are longer reported.

The FlatProfiler, deprecated in JDK 9, has been made obsolete by removing the implementation code. The FlatProfiler was enabled by setting the -Xprof VM argument. The -Xprof flag remains recognized in this release; however, setting it will print out a warning message.

The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: sigset, signal and sigaction. Only sigaction is a cross-platform, supported, API for multi-threaded processes. Both signal and sigset are considered obsolete on those platforms that still define them. Consequently, the use of signal and sigset with the signal-chaining facility are now deprecated, and support for their use will be removed in a future release.

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u341) be used after the next critical patch update scheduled for October 18, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u341) on 2022-11-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

The TLSv1.3 implementation is available in JDK 8u from 8u261 and enabled by default for server roles but disabled by default for client roles. From this release onwards, TLSv1.3 is now also enabled by default for client roles. You can find more details in the Additional Information section of the Oracle JRE and JDK Cryptographic Roadmap.

Note that TLS 1.3 is not directly compatible with previous versions. Enabling it on the client may introduce compatibility issues on either the server or the client side. Here are some more details on potential compatibility issues that you should be aware of:

• 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.
• The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use non-supported signature algorithms.
• 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.
• 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, for example TLS_AES_128_GCM_SHA256 (1.3 and later) versus TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (1.2 and earlier).
• The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols.
• TLS 1.3 requires that the implementation support new cryptographic algorithms which previous versions of TLS did not, such as RSASSA-PSS. If your application is configured to use 3rd party JCE provider(s) which do not support the required algorithms, you may get handshake failures.

Support has been added for TLS channel binding tokens for Negotiate/Kerberos authentication over HTTPS through javax.net.HttpsURLConnection.

Channel binding tokens are increasingly required as an enhanced form of security. They work by communicating from a client to a server the client's understanding of the binding between connection security (as represented by a TLS server cert) and higher level authentication credentials (such as a username and password). The server can then detect if the client has been fooled by a MITM and shutdown the session/connection.

The feature is controlled through a new system property `jdk.https.negotiate.cbt` which is described fully as below:

jdk.https.negotiate.cbt (default: "never")

This controls the generation and sending of TLS channel binding tokens (CBT) when Kerberos or the Negotiate authentication scheme using Kerberos are employed over HTTPS with HttpsURLConnection. There are three possible settings:

• "never". This is also the default value if the property is not set. In this case, CBTs are never sent.
• "always". CBTs are sent for all Kerberos authentication attempts over HTTPS.
• "domain:" Each domain in the list specifies destination host or hosts for which a CBT is sent. Domains can be single hosts like foo, or foo.com, or literal IP addresses as specified in RFC 2732, or wildcards like *.foo.com which matches all hosts under foo.com and its sub-domains. CBTs are not sent to any destinations that don't match one of the list entries

The channel binding tokens generated are of the type "tls-server-end-point" as defined in RFC 5929.

The java.net.InetAddress class has been updated to strictly accept IPv4 address literals in decimal quad notation. The InetAddress class methods are updated to throw an java.net.UnknownHostException for invalid IPv4 address literals. To disable this check, the new "jdk.net.allowAmbiguousIPAddressLiterals" system property can be set to "true".

On oracle.com and java.com, certain JDK bundle extensions are getting truncated on download when using Firefox version 102. The downloaded bundles have no file extension like ".exe", ".rpm", ".deb". If you are not able to upgrade to Firefox ESR 102.0.1 or Firefox 103 when it is released, then as a workaround you can:

• manually add a file extension to the file name after download.
• use a different browser

java.util.Vector is updated to correctly report ClassNotFoundException that occurs during deserialization using java.io.ObjectInputStream.GetField.get(name, object) when the class of an element of the Vector is not found. Without this fix, a StreamCorruptedException is thrown that does not provide information about the missing class.

DeflaterOutputStream.close() and GZIPOutputStream.finish() methods have been modified to close out the associated default JDK compressor before propagating a Throwable up the stack. ZIPOutputStream.closeEntry() method has been modified to close out the associated default JDK compressor before propagating an IOException, not of type ZipException, up the stack.

For JVMs running in a container, OperatingSystemMXBean.getProcessCpuLoad now considers only the CPU resources available to the container when calculating CPU load. Prior to this change, the calculation included all CPUs on a host. After this change, management agents may report higher CPU usage by JVMs in containers that are constrained to a limited set of CPUs.

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u333) be used after the next critical patch update scheduled for July 19, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u333) on 2022-08-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

The Windows implementation of java.io.File allows access to NTFS Alternate Data Streams (ADS) by default. Such streams have a structure like “filename:streamname”. A system property jdk.io.File.enableADS has been added to control this behavior. To disable ADS support in java.io.File, the system property jdk.io.File.enableADS should be set to false (case ignored). Stricter path checking however prevents the use of special devices such as NUL:

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u331) be used after the next critical patch update scheduled for July 19, 2022.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u331) on 2022-08-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

Three processing limits have been added. These are:

• jdk.xml.xpathExprGrpLimit

Description: Limits the number of groups an XPath expression can contain.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10.

• jdk.xml.xpathExprOpLimit

Description: Limits the number of operators an XPath expression can contain.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 100.

• jdk.xml.xpathTotalOpLimit

Description: Limits the total number of XPath operators in an XSL Stylesheet.

Type: integer

Value: A positive integer. A value less than or equal to 0 indicates no limit. If the value is not an integer, a NumberFormatException is thrown. Default 10000.

Supported processors

• jdk.xml.xpathExprGrpLimit and jdk.xml.xpathExprOpLimit are supported by the XPath processor.

• All three limits are supported by the XSLT processor.

Setting properties

For the XSLT processor, the properties can be changed through the TransformerFactory. For example,

        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");

For both the XPath and XSLT processors, the properties can be set through the system property and jaxp.properties configuration file located in the conf directory of the Java installation. For example,

        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");

or in the jaxp.properties file,

        jdk.xml.xpathExprGrpLimit=20

There are two known issues:

1. An XPath expression that contains a short form of the parent axis ".." can return incorrect results. See JDK-8284920 for details.
2. An invalid XPath expression that ends with a relational operator such as ‘<’ ‘>’ and ‘=’ will cause the processor to erroneously throw StringIndexOutOfBoundsException instead of XPathExpressionException. See JDK-8284548 for details.

On macOS, only certificates with proper trust settings in the user keychain will be exposed as trusted certificate entries in the KeychainStore type of keystore. Also, calling the KeyStore::setCertificateEntry method or the keytool -importcert command on a KeychainStore keystore now fails with a KeyStoreException. Instead, call the macOS "security add-trusted-cert" command to add a trusted certificate into the user keychain.

The gencert command of the keytool utility has been updated to create AKID from the SKID of the issuing certificate as specified by RFC 5280.

The parsing of URLs in the LDAP, DNS, and RMI built-in JNDI providers has been made more strict. The strength of the parsing can be controlled by system properties:

  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict"    (to control "ldap:" URLs)

  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict"     (to control "dns:" URLs)
  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict"     (to control "rmi:" URLs)
  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict"   (to control "iiop:" and "iiopname:" URLs) 

The default value is "compat" for all of the three providers.

• The "legacy" mode turns the new validation off.
• The "compat" mode limits incompatibilities.
• The "strict" mode is stricter and may cause regression by rejecting URLs that an application might consider as valid.

In "compat" and "strict" mode, more validation is performed. As an example, in the URL authority component, the new parsing only accepts brackets around IPv6 literal addresses. Developers are encouraged to use java.net.URI constructors or its factory method to build URLs rather than handcrafting URL strings.

If an illegal URL string is found, a java.lang.IllegalArgumentException or a javax.naming.NamingException (or a subclass of it) is raised.

• Jordan now starts DST on February's last Thursday.
• Samoa no longer observes DST.
• Merge more location-based Zones whose timestamps agree since 1970.
• Move some backward-compatibility links to 'backward'.
• Rename Pacific/Enderbury to Pacific/Kanton.
• Correct many pre-1993 transitions in Malawi, Portugal, etc.
• zic now creates each output file or link atomically.
• zic -L no longer omits the POSIX TZ string in its output.
• zic fixes for truncation and leap second table expiration.
• zic now follows POSIX for TZ strings using all-year DST.
• Fix some localtime crashes and bugs in obscure cases.
• zdump -v now outputs more-useful boundary cases.
• tzfile.5 better matches a draft successor to RFC 8536.
• A new file SECURITY.
• Revert most 2021b changes to 'backward'.
• Fix 'zic -b fat' bug in pre-1970 32-bit data.
• Fix two Link line typos.
• Distribute SECURITY file.

This release is intended as a bugfix release, to fix compatibility problems and typos reported since 2021b was released.

• Fiji suspends DST for the 2021/2022 season.
• 'zic -r' marks unspecified timestamps with "-00".
• Palestine will fall back 10-29 (not 10-30) at 01:00.

SunPKCS11 provider adds new provider configuration attributes to better control native resources usage. The SunPKCS11 provider consumes native resources in order to work with native PKCS11 libraries. To manage and better control the native resources, additional configuration attributes are added to control the frequency of clearing native references as well as whether to destroy the underlying PKCS11 Token after logout.

The 3 new attributes for SunPKCS11 provider configuration file are:

1. destroyTokenAfterLogout (boolean, defaults to false)

   If set to true, when java.security.AuthProvider.logout() is called upon the SunPKCS11 provider instance, the underlying Token object will be destroyed and resources will be freed. This essentially renders the SunPKCS11 provider instance unusable after logout() calls. Note that a PKCS11 provider with this attribute set to true should not be added to the system provider list since the provider object is not usable after a logout() method call.

2. cleaner.shortInterval (integer, defaults to 2000, in milliseconds)

   This defines the frequency for clearing native references during busy period (such as, how often should the cleaner thread processes the no-longer-needed native references in the queue to free up native memory). Note that the cleaner thread will switch to the 'longInterval' frequency after 200 failed tries (such as, when no references are found in the queue).

3. cleaner.longInterval (integer, defaults to 60000, in milliseconds)

   This defines the frequency for checking native reference during non-busy period (such as, how often should the cleaner thread check the queue for native references). Note that the cleaner thread will switch back to the 'shortInterval' value if native PKCS11 references for cleaning are detected.

Two new system properties have been added. The system property, jdk.tls.client.disableExtensions, is used to disable TLS extensions used in the client. The system property, jdk.tls.server.disableExtensions, is used to disable TLS extensions used in the server. If an extension is disabled, it will be neither produced nor processed in the handshake messages.

The property string is a list of comma separated standard TLS extension names, as registered in the IANA documentation (for example, server_name, status_request, and signature_algorithms_cert). Note that the extension names are case sensitive. Unknown, unsupported, misspelled and duplicated TLS extension name tokens will be ignored.

Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to be established if a mandatory extension is disabled. Please do not disable mandatory extensions, and do not use this feature unless you clearly understand the impact.

The following root certificate from Google has been removed from the cacerts keystore:

+ alias name "globalsignr2ca [jdk]"

  Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2

IANA Time Zone Database, on which JDK's Date/Time libraries are based, has made a tweak to some time zone rules since 2021c. Note that since this update, some of the time zone rules prior to the year 1970 have been modified according to the changes which were introduced with 2021b. For more detail, refer to the announcement of 2021b

This release reverts the behavior of SSLSocketImpl and SSLTransport introduced by JDK-8196584. SocketException will now be thrown as is instead of being suppressed into an SSLException.

For more information, refer to Timezone Data Versions in the JRE Software.

Starting from version 8u311, the Marlin graphics rasterizer and its artifacts will be built and distributed as a part of the JDK/JRE bundles. It is not the default rendering engine, however there is an option to enable it by setting the following system property:

sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine

Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each deserialization stream. The behavior is a strict subset of JEP 415: Context-Specific Deserialization Filters to allow a filter factory to be configured using a property configured on the command line or in the security properties file.

The behavior is opt-in based on the presence of the jdk.serialFilterFactory system property on the command line or the jdk.serialFilterFactory security property. If set, the JVM-wide filter factory selects the filter for each stream when the stream is constructed and when a stream-specific filter is set.

The JVM-wide filter factory is a java.util.function.BinaryOperator<sun.misc.ObjectInputFilter> function invoked when each ObjectInputStream is constructed and when the stream-specific filter is set using sun.misc.ObjectInputFilter.Config.setObjectInputFilter(sun.misc.ObjectInputFilter). The parameters are the current filter and a requested filter and the function returns the filter to be used for the stream. When invoked from the ObjectInputStream constructors, the first parameter is null and the second parameter is the static JVM-wide filter. When invoked from sun.misc.ObjectInputFilter.Config.setObjectInputFilter(sun.misc.ObjectInputFilter), the first parameter is the filter currently set on the stream (which was set in the constructor), and the second parameter is the filter requested.

A typical filter factory should use or merge the static JVM-wide filter with other application and context specific filters and the stream-specific filter, if one is set on the stream. The filter factory implementation can also use any contextual information at its disposal, for example, extracted from the application thread context, or its call stack, to compose and combine a new filter. It is not restricted to only use its two parameters.

Refer to Context-Specific Deserialization Filter and Serialization Filtering Guide for details.

The following root certificate from IdenTrust has been removed from the cacerts keystore:

+ alias name "identrustdstx3 [jdk]"

  Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.

This release doesn't correctly identify Windows 11. The property os.name is set to Windows 10 on Windows 11. In HotSpot error logs, the OS is identified as Windows 10; however, the HotSpot error log does show the Build number. Windows 11 has Build 22000.194 or above.

The default priority order of the cipher suites for TLS 1.0 to TLS 1.3 has been adjusted.

For TLS 1.3, TLS_AES_256_GCM_SHA384 is now preferred over TLS_AES_128_GCM_SHA256.

For TLS 1.0 to TLS 1.2, some of the intermediate suites have been lowered in priority as follows:

• Cipher suites that do not preserve forward secrecy have been moved lower in priority than those that do support forward secrecy.
• Cipher suites that use SHA-1 have been moved lower in priority.
See JDK-8163326

The behavior of HttpURLConnection when using ProxySelector has been modified in this JDK release. HttpURLConnection used to fall back to a direct connection attempt if the configured proxy(s) failed to make a connection. Beginning with this release, the default behavior has been changed to no longer use a direct connection when the first proxy connection attempt fails.

A new system property, sun.net.http.fallbackToDirect, can be set to a value of "true" should an application need to fall back to the old behavior (fall back to a direct connection when the first proxy connection attempt fails).

The scope of the com.sun.jndi.ldap.object.trustSerialData system property has been extended to control the deserialization of java objects from the javaReferenceAddress LDAP attribute. This system property now controls the deserialization of java objects from the javaSerializedData and javaReferenceAddress LDAP attributes.

To prevent deserialization of java objects from these attributes, the system property can be set to false. By default, the deserialization of java objects from javaSerializedData and javaReferenceAddress attributes is allowed.

This release doesn't correctly identify Windows Server. The property os.name is set to Windows 2019 on Windows Server 2022. In HotSpot error logs, the OS is identified as Windows 10.0 for Windows Server releases 2016, 2019, and 2022; however, the HotSpot error log does show the Build number. Windows Server 2016 has Build 14393 or above, Windows Server 2019 has Build 17763 or above, and Windows Server 2022 has Build 20348 or above.

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

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.