Two new switches, -XX:+ErrorFileToStdout and -XX:+ErrorFileToStderr, have been added. When either switch is specified and a fatal error occurs, the JVM redirects the crash report content that would normally be written to the hs_err file to stdout or stderr, respectively.

If a JavaFX application attempts to create a WebView node on a 32-bit JDK, the following exception will be thrown:

java.lang.UnsupportedOperationException: WebView is not supported on this platform

All TLS server certificates anchored by Symantec, Entrust, and Camerfirma root CAs are now distrusted, regardless of their issuing date. TLS server certificates anchored by Chunghwa root CAs will be completely distrusted as of April 19, 2027. The jdk.security.caDistrustPolicies security property in the java.security configuration file has been updated to reflect these new policies.

The following warning is now printed when the JavaFX runtime is initialized:

WARNING: Update releases of JDK 8 after March 2028 will not include JavaFX.

Visit https://www.oracle.com/javase/javafx for details.

This is intended to give notice of the upcoming removal of JavaFX to a wider audience. The runtime warning may be suppressed by setting the javafx.suppress.removal.warning system property, for example:

java -Djavafx.suppress.removal.warning ...

The com.sun.net.http.HttpServer has been updated to validate the Host request header as described in RFC 9112. HTTP/1.1 requests without a Host header or with multiple Host headers are now rejected with an HTTP 400 Bad Request response.

The validation can be disabled by setting the system property sun.net.httpserver.disableHostValidation to true.

The sun.rmi.transport.proxy.CGIHandler class, which provides the server-side Java RMI CGI command handler used for HTTP-to-CGI tunneling, is now disabled by default. This change does not affect RMI connections made directly over TCP or HTTP; it affects deployments that invoke this legacy class to forward tunneled RMI requests to another local port.

Deployments that require HTTP-to-CGI tunneling must pass -Djdk.rmi.server.disableCGI=false to the JVM that invokes sun.rmi.transport.proxy.CGIHandler. The java-rmi.cgi launcher script is no longer included in JDK images on Linux and Solaris, so administrators continuing to use this mechanism must configure a suitable CGI endpoint.

The implementation of the WebRowSet.readXml methods has been updated to consistently report XML parsing and validation failures as SQLException.

WebRowSet.readXml validates XML input against the standard WebRowSet XML schema. Applications should expect malformed XML, schema validation failures, unsupported external entities, and other XML processing errors to be reported as SQLException. Validation can be disabled by setting the system property jdk.sql.rowset.webrowsetValidation to false.

The existing method signatures remain unchanged. No specification changes are included in this update.

The scope of the com.sun.jndi.ldap.object.trustSerialData system property is extended to cover transparent processing of URL RMI and IIOP References obtained from an LDAP context.

A URL context factory is a special type of ObjectFactory that will be used to look up an object referred to from a JNDI javax.naming.Reference that does not specify any factory name, but contains a simple reference address in the form of a URL string. When deserialization of Java objects from LDAP is disabled, the JDK built-in implementation of the JNDI/LDAP provider will no longer transparently use any URL context factory when processing Reference objects containing a URL reference whose scheme is rmi, iiop, iiopname, and corbaname.

To make it possible to have a finer-grain control over which URL schemes should be disabled when processing URL string reference addresses from the built-in JNDI/LDAP provider, a new system property, jdk.jndi.ldap.disabledURLSchemes, is introduced. The value of this property is a comma-separated list of URL schemes that are disabled. The JDK built-in implementation of the JNDI/LDAP provider will no longer transparently use any URL context factory when processing Reference objects containing a URL reference whose scheme corresponds (case insensitively) to one of the schemes in this list of disabled schemes. The default value for that property is "rmi,iiop,iiopname,corbaname" if trustSerialData is false (the default), and empty if trustSerialData is true. If a custom value for this new property is provided on the Java command line then only schemes listed in that property value are disabled, regardless of the value of trustSerialData.

If rmi is included in this list (resp. iiop, iiopname, or corbaname), which is the default when no custom values have been supplied for com.sun.jndi.ldap.object.trustSerialData or jdk.jndi.ldap.disabledURLSchemes, then a javax.naming.Reference object will be returned to the application instead of the object that would have been created by processing the RMI reference (resp. IIOP reference) and looking up its URL from the context returned by a URL context factory.

An application that depends on following RMI or IIOP URLs contained in a Reference obtained from a JNDI/LDAP context may need to process the Reference object explicitly, or provide a custom value for jdk.jndi.ldap.disabledURLSchemes system property that does not include the rmi scheme (resp. iiop, iiopname, or corbaname schemes).

An application that wants to prevent transparent processing of other kinds of URL schemes can now do so by supplying a custom value for the jdk.jndi.ldap.disabledURLSchemes system property that includes them.

Deserialization of object graphs is disabled by default when reading data from the clipboard or during drag-and-drop operations. For a custom DataFormat, a directly serialized String is decoded by default; other serialized objects are returned as a ByteBuffer.

Applications can restore the previous ability to deserialize arbitrary object graphs by setting the javafx.dnd.deserializeObjectGraph system property to true.

The JDK CORBA implementation now limits the size of incoming GIOP messages and the estimated memory required for arrays, or closely related groups of arrays, created while decoding CORBA data.

The following system properties are available:

• com.sun.CORBA.giop.ORBMaxMessageSize

  Specifies the maximum accepted size, in bytes, of an incoming GIOP message, including message headers and fragments. The default is 16 MiB (16777216).

• com.sun.CORBA.giop.ORBMaxArrayAllocationSize

  Specifies the maximum estimated size, in bytes, of an individual Java array allocated while unmarshalling incoming CORBA data. The default is 16 MiB (16777216).

The array limit is based on the estimated storage required by the array. Primitive elements use their corresponding primitive size. Java reference array elements are conservatively estimated as eight bytes each. The limit does not represent the total memory consumed by all objects referenced from an array or by all concurrently processed requests.

If the incoming-message limit is exceeded, the JDK ORB rejects the message with an org.omg.CORBA.MARSHAL exception. If an array-allocation limit is exceeded during decoding, unmarshalling fails with MARSHAL.

The properties can be set on the Java command line, for example:

java \

  -Dcom.sun.CORBA.giop.ORBMaxMessageSize=33554432 \
  -Dcom.sun.CORBA.giop.ORBMaxArrayAllocationSize=67108864 \
  Application

They may also be supplied in the Properties passed to ORB.init:

Properties properties = new Properties();

properties.setProperty(
    "com.sun.CORBA.giop.ORBMaxMessageSize", "33554432");
properties.setProperty(
    "com.sun.CORBA.giop.ORBMaxArrayAllocationSize", "67108864");

ORB orb = ORB.init(args, properties);

The properties are independent. For example, an application can retain a 16 MiB incoming-message limit while permitting a compact message to produce a larger decoded array.

These limits apply when the JDK ORB receives data: on servers receiving requests and on clients receiving replies or callbacks. They do not change IDL sequence bounds and are specific to the JDK CORBA implementation.

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

+ alias name "luxtrustglobalrootca [jdk]"

  Distinguished Name: CN=LuxTrust Global Root, O=LuxTrust s.a., C=LU

Deserialization of the com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl class is now disabled by default. (This is an internal class that implements the javax.xml.transform.Templates interface.) An application attempting to deserialize an instance of this class will receive UnsupportedOperationException. To re-enable deserialization of this class, use the command line to set the system property jdk.xml.enableTemplatesImplDeserialization to true. Prior to this change, deserialization was enabled by default, unless the Security Manager was enabled. The state of the Security Manager is no longer considered in determining whether deserialization is enabled.