RELEASE NOTES: JDK 26

Inner Classes of Type Parameters Emitted As Raw Types in Signatures

Whenever a reference to an inner type of the kind A.B is found, javac needs to normalize the qualifier type A, so that any reference to potentially parameterized types are made explicit. This normalization occurs regardless of whether this type is explicitly provided in the source code, or inferred from the enclosing context. Some cases were found where no normalization was applied to the type qualifier -- e.g. if the qualifier is a type-variable type. The lack of normalization led to spurious errors, as the type reference was incorrectly classified as a raw type. This change adds the missing normalization step. While this change is generally beneficial, as spurious errors that would cause compilation to fail are no longer generated, there might be cases where the additional normalization steps might result in a change in overload resolution.

For example, assume the following snippet in which the result of the getter.get() method call is passed to an overloaded method with two candidates: m(T) and M(Object). Without the patch the following code prints Object, erroneously; with the patch the following code prints T, correctly. An erroneous classification of the qualified type means that the type G.Getter was treated as a raw type and the result of the method call was Object; the correct classification is to treat it as T <: Number and the return type of the method call to be Number. That very classification selects a different overload m before and after the patch:

static class Usage<T extends Number, G extends Getters<T>> {
    public void test(G.Getter getter) {
        m(getter.get()); // javac selects one of the overloads for m
    }
    void m(T t)       { System.out.println("T");   }
    void m(Object s)  { System.out.println("Object");  }
}

static abstract class Getters<T> {
    abstract class Getter {
        abstract T get();
    }
}

public static void main(String[] args) {
    new Usage<Integer, Getters<Integer>>().test(new Getters<Integer>() {}.new Getter() { Integer get() { return 42; } });
}

Remove XML Interchange in java.management/javax/management/modelmbean/DescriptorSupport

The deprecated XML interchange feature in javax.management.modelmbean.DescriptorSupport is removed, meaning the constructor DescriptorSupport(String inStr) and the method toXMLString() are removed. Also the class javax.management.modelmbean.XMLParseException is removed, which it would have been an error for code outside the package to have used for its own purposes.

AttributeList, RoleList, and UnresolvedRoleList Should Never Accept Other Types of Object

The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have historicallly accepted objects of the wrong type, and only verified types when (and after) the "asList()" method is called. This feature has been removed, and these classes never accept the wrong kind of Object. Most applications using these classes should not be affected.

JMXServiceURL Requires an Explicit Protocol

The class javax.management.remote.JMXServiceURL requires that a protocol is specified when using its String constructor, and will throw MalformedURLException if the protocol is missing. This behaviour is now extended to the other constructors that take individual parameters, and the historical defaulting to the "jmxmp" protocol is removed.

Deallocate jmethodID native memory

The internal representation of native method pointers jmethodID has been changed to no longer be a pointer to the JVM representation of the method. Native code that breaks the abstraction of jmethodID to assume this representation will stop working in JDK 26. jmethodID is now a unique identifier that the JVM maps to the native JVM Method.

Added 4 New Root Certificates from Sectigo Limited

The following root certificates have been added to the cacerts truststore: ``` + Sectigo Limited + sectigocodesignroote46 DN: CN=Sectigo Public Code Signing Root E46, O=Sectigo Limited, C=GB

• Sectigo Limited

• sectigocodesignrootr46 DN: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB

• Sectigo Limited

• sectigotlsroote46 DN: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB

• Sectigo Limited

• sectigotlsrootr46 DN: CN=Sectigo Public Server Authentication Root R46, O=Sectigo Limited, C=GB ```

SocketPermission Class Deprecated for Removal

The java.net.SocketPermission class has been deprecated for removal. This permission cannot be used for controlling access to resources as the Security Manager is no longer supported.

Removed Four AffirmTrust Root Certificates

The following root certificates, which are deactivated and no longer in use, have been removed from the cacerts keystore:

``` + alias name "affirmtrustcommercialca [jdk]" Distinguished Name: CN=AffirmTrust Commercial, O=AffirmTrust, C=US

• alias name "affirmtrustnetworkingca [jdk]" Distinguished Name: CN=AffirmTrust Networking, O=AffirmTrust, C=US

• alias name "affirmtrustpremiumca [jdk]" Distinguished Name: CN=AffirmTrust Premium, O=AffirmTrust, C=US

• alias name "affirmtrustpremiumeccca [jdk]" Distinguished Name: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US ```

Removed DESede and PKCS1Padding Algorithms from Requirements and Added PBES2 Algorithms

The following security algorithm implementation requirements in the Java Security Standard Algorithm Names specification and the API specifications have been removed as they are no longer recommended and should not be in wide usage anymore:

AlgorithmParameters: DESede
Cipher:
    DESede/CBC/NoPadding
    DESede/CBC/PKCS5Padding
    DESede/ECB/NoPadding
    DESede/ECB/PKCS5Padding
    RSA/ECB/PKCS1Padding
KeyGenerator: DESede
SecretKeyFactory: DESede

The following PBES2 algorithms from RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 have been added as new requirements:

AlgorithmParameters:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
Cipher:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
Mac:
    PBEWithHmacSHA256
SecretKeyFactory:
    PBEWithHmacSHA256AndAES_128
    PBEWithHmacSHA256AndAES_256
    PBKDF2WithHmacSHA256

Performance Regression in java.lang.ClassValue::get

JDK-8351996 updated ClassValue in JDK 25 to make it more robust in various threading conditions. Unfortunately, this update caused ClassValue.get to run more slowly after a call to ClassValue.remove. Most applications do not use ClassValue directly, but libraries which call both ClassValue.get and remove may be affected by the slowdown. An example of a library affected by the slowdown is the standard library in Scala 2.12. The slowdown is fixed in in JDK-8358535.

User-specified SecureRandom Object in XML Signature Generation

A new property called "jdk.xmldsig.SecureRandom" has been added to DOMSignContext so you can use your own SecureRandom instance. To use this property, call signContext.setProperty("jdk.xmldsig.SecureRandom", yourSecureRandom) before calling XMLSignature.sign(signContext).

Disable XPath in XML Signatures

XML signatures that use XPath transforms have been disabled by default. The XPath transform is not recommended by the XML Signature Best Practices document. Applications should use the XPath Filter 2.0 transform instead, which was designed to be an alternative to the XPath transform. If necessary, and at their own risk, applications can workaround this policy by modifying the jdk.xml.dsig.secureValidationPolicy security property and re-enabling the XPath transform.

`java.text.DecimalFormat` Now Uses the `Double.toString(double)` Algorithm

Class java.text.DecimalFormat now uses the algorithm implemented in Double.toString(double) and in java.util.Formatter to format floating-point values.

As a consequence, in rare cases the outcome might be slightly different than with the old algorithm. For example, the double 7.3879E20 now produces "738790000000000000000" rather than "738790000000000100000" given appropriate formatting specifications.

To help migrating applications that might be impacted by this change, for a few releases the old algorithm will still be available to DecimalFormat and classes that depend on it, like NumberFormat. The old algorithm can be enabled with the "-Djdk.compat.DecimalFormat=true" option on the launcher command line. Absent this option, the new algorithm is used.

Support Algorithm Constraints and Certificate Checks in SunX509 Key Manager

The default "SunX509" KeyManagerFactory for TLS now supports the same algorithm constraints and certificate check functionality as the "PKIX" KeyManagerFactory. Selection and prioritization of the local certificates chosen by the KeyManager is based on the following checks:

1) Local certificates are checked against peer supported certificate signature algorithms sent with the signature_algorithms_cert TLS extension. 2) Local certificates are checked against TLS algorithm constraints specified in the jdk.tls.disabledAlgorithms and jdk.certpath.disabledAlgorithms security properties. 3) Local certificates are prioritized based on validity period and certificate extensions.

The legacy behavior (no checking of local certificates) of the "SunX509" key manager can be restored by setting the jdk.tls.SunX509KeyManager.certChecking system property to false.