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.