JDK 26 Early-Access Release Notes

This is a draft of the release notes that will accompany JDK 26. The contents are subject to change until release.

Build 10

Support Algorithm Constraints and Certificate Checks in SunX509 Key Manager (JDK-8359956)

security-libs/javax.net.ssl

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.

Build 9

Removed Four AffirmTrust Root Certificates (JDK-8361212)

security-libs/java.security

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 (JDK-8361964)

security-libs/java.security

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

Build 8

SocketPermission Class Deprecated for Removal (JDK-8356557)

core-libs/java.net

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.

Build 7

Inner Classes of Type Parameters Emitted As Raw Types in Signatures (JDK-8357653)

tools/javac

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; } });
}

AttributeList, RoleList, and UnresolvedRoleList Should Never Accept Other Types of Object (JDK-8359809)

core-svc/javax.management

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.

Build 6

Remove XML Interchange in java.management/javax/management/modelmbean/DescriptorSupport (JDK-8351413)

core-svc/javax.management

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.

Build 5

Deallocate jmethodID native memory (JDK-8268406)

hotspot/runtime

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.

Build 3

JMXServiceURL Requires an Explicit Protocol (JDK-8347114)

core-svc/javax.management

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.

Disable XPath in XML Signatures (JDK-8314180)

security-libs/javax.xml.crypto

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.