Java JDK 24.0.1

What's new in this version:

Fixed:
core-svc/javax.management➜ Resolved: OperatingSystemMXBean CpuLoad() Methods Return -1.0 on Windows (JDK-8350820):
- On Windows, the OperatingSystemMXBean CPU load methods, getSystemCpuLoad, getCpuLoad, and getProcessCpuLoad, were failing and always returning -1. This error affected CPU usage monitoring of Windows targets. This is resolved in this release.

Other Notes:
security-libs/javax.net.ssl➜ Distrust TLS Server Certificates Anchored by Camerfirma Root Certificates and Issued After April 15, 2025 (JDK-8346587):
- The JDK will stop trusting TLS server certificates issued after April 15, 2025 and anchored by Camerfirma root certificates, in line with similar plans announced by Google, Mozilla, Apple, and Microsoft.
- TLS server certificates issued on or before April 15, 2025 will continue to be trusted until they expire. Certificates issued after that date, and anchored by any of the Certificate Authorities in the table below, will be rejected.
- The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below and the certificate has been issued after April 15, 2025.

An application will receive an exception with a message indicating the trust anchor is not trusted, for example:
- "TLS Server certificate issued after 2025-04-15 and anchored by a distrusted legacy
- Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A.,
- SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU"
- The JDK can be configured to trust these certificates again by removing "CAMERFIRMA_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Camerfirma Root certificates included in the JDK:
- CN=Chambers of Commerce Root,
- CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid
- CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:
- keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>
- If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server.

core-svc/tools➜ JarInputStream Treats Signed JARs with Multiple Manifests As Unsigned (JDK-8337494 (not public)):
- The JarInputStream class now treats a signed JAR as unsigned if it detects a second manifest within the first two entries in the JAR file. A warning message "WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned." is logged if the system property, -Djava.security.debug=jar, is set.

security-libs/java.security➜ Compatible OCSP readtimeout Property with OCSP Timeout (JDK-8347506):
- In JDK 21, an enhanced syntax for various timeout properties was released through JDK-8179502. This included a new system property, com.sun.security.ocsp.readtimeout, which allows users to control the timeout while reading OCSP responses after a successful TCP connection has been established.
- This changes the default posture of this property to be the value of the com.sun.security.ocsp.timeout system property from its original default of 15 seconds. If the com.sun.security.ocsp.timeout system property is also not set, then its default 15 second timeout is propagated to the default for com.sun.security.ocsp.readtimeout.

Fixed:
- Limit the length of inflated text chunks
- Improve AnnotationFormatError message for duplicate annotation interfaces
- Epsilon: Demote heap size and AlwaysPreTouch warnings to info level
- ZGC: Crash in DependencyContext::clean_unloading_dependents
- Output JVMTI agent information in hserr files
- cpuset cgroups controller is required for no good reason
- Restore null return for invalid services from legacy providers
- 'internal proprietary API' warnings make javac warnings unusable