Enterprise Performance Pack Release Notes
Java™ SE Development Kit 8, Update 451 Enterprise Performance Pack (JDK 8u451-PERF)
Release date: April 15, 2025
The full version string for this update release is 1.8.0_451-perf-b09 (where "b" means "build"). The version number is 1.8.0_451-perf.
IANA TZ Data 2025a
JDK 8u451 contains IANA time zone data 2025a which contains the following changes since the previous update.
- Paraguay adopts permanent -03 starting spring 2024.
- Improve pre-1991 data for the Philippines.
- Etc/Unknown is now reserved.
For more information, refer to Timezone Data Versions in the JRE Software.
Security Baselines
The security baselines for the Java Runtime at the time of the release of JDK 8u451 are specified in the following table:
| Java Family Version | Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_451-perf-b09 |
Keeping the JDK up to Date
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 8u451) be used after the next critical patch update scheduled for July 15, 2025.
Java Management Service, available to all users, can help you find vulnerable Java versions in your systems. Java SE Subscribers and customers running in Oracle Cloud can use Java Management Service to update Java Runtimes and to do further security reviews like identifying potentially vulnerable third party libraries used by your Java programs. Existing Java Management Service user click here to log in to your dashboard. The Java Management Service Documentation provides a list of features available to everyone and those available only to customers. Learn more about using Java Management Service to monitor and secure your Java Installations.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u451) on 2025-08-15. 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.
New Features
Native PKCS11 mechanisms which support decryption but not encryption, or signature verification but not signing, are considered legacy and are disabled by default. The legacy mechanism check in SunPKCS11 provider is enhanced with the service type. For example, prior to this fix, a mechanism supporting encryption, decryption, and verification but not signing, is considered legacy and can't be used at all. After this fix, the corresponding Cipher service using this mechanism is available since both encryption and decryption are supported. However, the corresponding Signature service is not since only verification is supported. To bypass the legacy mechanism check, set the PKCS11 provider configuration attribute "allowLegacy" to true. The default value is false. Note that it is the caller's responsibility to make sure the legacy mechanism is not used for the unsupported functionality.
Other Notes
In prior releases, JNI_GetCreatedJavaVMs:
jint JNI_GetCreatedJavaVMs(JavaVM **vmBuf, jsize bufLen, jsize *nVMs);
could return a JavaVM, via the vmBuf array, that was still in the process of being initialized and may not be ready for use. This has now changed so that it will only return fully initialized VMs. It is important that the programmer checks that the returned number of VMs, in nVMs, is greater than zero, before trying to use any vmBuf entries.
JDK 17 introduced a performance improvement that made OCSP clients unconditionally use GET requests for small requests, while doing POST requests for everything else. This is explicitly allowed and recommended by RFC 5019 and RFC 6960. However, we have seen OCSP responders that, despite RFC requirements, are not working well with GET requests.
This release introduces a new JDK system property to allow clients to fallback to POST-only behavior. This unblocks interactions with those OCSP responders through the use of -Dcom.sun.security.ocsp.useget={false,true}. This amends the original change that introduced GET OCSP requests (JDK-8179503). The default behavior is not changed; the option defaults to true. Set the option to false to disable GET OCSP requests. Any value other than false (case-insensitive) defaults to true.
This option is non-standard, and might go away once problematic OCSP responders get upgraded.
Changes in Java SE 8u451-Perf
Bug Fixes
JDK 8u451 Enterprise Performance Pack includes the following fixes from JDK 17:| # | BugId | Component | Summary |
|---|---|---|---|
| 1 | JDK-8338100 | hotspot/compiler | C2: assert(!n_loop->is_member(get_loop(lca))) failed: control must not be back in the loop |
| 2 | JDK-8269516 | hotspot/compiler | AArch64: Assembler cleanups |
| 3 | JDK-8325937 | hotspot/runtime | runtime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64 |
| 4 | JDK-8344145 | hotspot/test | Remove windows_x64_1803_or_later and it's usages in task definitions |