Release date: October 15, 2024
The full version string for this update release is 1.8.0_431-perf-b11 (where "b" means "build"). The version number is 1.8.0_431-perf.
For more information, refer to Timezone Data Versions in the JRE Software.
The security baselines for the Java Runtime at the time of the release of JDK 8u431 are specified in the following table:
Java Family Version | Security Baseline (Full Version String) |
---|---|
8 | 1.8.0_431-perf-b11 |
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 8u431) be used after the next critical patch update scheduled for January 21, 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 8u431) on 2025-02-21. 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 java.security.debug
system property now accepts arguments which add thread ID, thread name, caller information, and timestamp information to debug statements for all components or a specific component.
+timestamp
can be appended to debug options to print a timestamp for that debug option. +thread
can be appended to debug options to print thread and caller information for that debug option.
Examples: -Djava.security.debug=all+timestamp+thread
adds timestamp and thread information to every debug statement generated.
-Djava.security.debug=properties+timestamp
adds timestamp information to every debug statement generated for the properties
component.
You can also specify -Djava.security.debug=help
which will display a complete list of supported components and arguments.
See Printing Thread and Timestamp Information for more information.
Fixed the issue with entries in the "java" and "javac" groups not being properly managed during an RPM upgrade.
Upgrading from an older Java RPM installed into a shared directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}
) to a Java RPM installing into a version-specific directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}
), results in the older Java entries in the "java" and "javac" groups not being deleted.
The issue does not manifest until the new Java is uninstalled. When it is uninstalled and Java from the lower release is installed, running Java commands like java
or keytool
without the full path specified will result in the "command not found" error. For example, install 21.0.3; upgrade it to 21.0.4; uninstall 21.0.4; install any Java update of 17 or 11 or 8 release; run "java" from the command line. The command will fail with the "command not found" error.
Manually delete orphan Java entries in the "java" and "javac" groups to workaround the issue.
The following root certificates have been added to the cacerts truststore:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
This JDK release relaxes the specification of java.awt.Robot
to account for possible platform and desktop environment access restrictions or limitations.
In the JDK, java.text.MessageFormat
now has an implementation limit for the ArgumentIndex
pattern element. The hard limit for the value is 10,000.
If an ArgumentIndex
value is equal to or exceeds the upper limit, an IllegalArgumentException
will now be thrown by
MessageFormats
constructorsapplyPattern(String pattern)
instance methodformat(String pattern, Object... arguments)
static methodDe-serializing a MessageFormat
object with an ArgumentIndex
value at or over the limit will throw an InvalidObjectException
.
The showSettings
launcher option no longer prints available locales information by default, when -XshowSettings
is used. The -XshowSettings:locale
option will continue to print all settings related to available locales.
New, default limits have been added to HTTP in the JDK.
The JDK built-in implementation of the URL protocol handler for HTTP (HttpURLConnection
) now has a default limit on the maximum response headers size that will be accepted from a remote party. The limit is set by default at 384kB (393216 bytes) and is computed as the cumulative size of all header names and header values plus an overhead of 32 bytes per header name value pair.
The default value of the limit can be changed by specifying a positive value with the jdk.http.maxHeaderSize
system property on the command line, or in the conf/net.properties file. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.
The JDK built-in implementation of the com.sun.net.httpserver.HttpServer
implements a similar limit for the maximum request header size the server is prepared to accept. The HttpServer
limit can be changed by specifying a positive value with the sun.net.httpserver.maxReqHeaderSize
system property on the command line. A negative or zero value is interpreted as no limit. The limit is set by default at 384kB (393216 bytes) and the size is computed in the same way as explained above. If the limit is exceeded, the connection is closed.
# | BugId | Component | Summary |
---|---|---|---|
1 | JDK-8005885 | hotspot/compiler | enhance PrintCodeCache to print more data |
2 | JDK-8329126 | hotspot/compiler | No native wrappers generated anymore with -XX:-TieredCompilation after JDK-8251462 |