RELEASE NOTES: JDK 25

Added TLSv1.3 and CNSA 1.0 Algorithms to Implementation Requirements

TLSv1.3 and CNSA 1.0 algorithms have been added to the list of cryptographic requirements all Java SE implementations must support. All cryptographic algorithms that are needed to implement the TLSv1.3 cipher suites and signature mechanisms and that are defined by RFC 8446 as MUST or SHOULD requirements have been added. All algorithms that are required by CNSA 1.0 have also been added. No required algorithms or protocols are being removed at this time.

The following requirements have been added to the Security Algorithm Implementation Requirements section of the Java Security Standard Algorithm Names specification and to the class summary of each of the APIs below.

• AlgorithmParameters

• ChaCha20-Poly1305

• EC with secp256r1 or secp384r1 curves

• RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm

• Cipher

• AES/GCM/NoPadding with 256 bit key size

• ChaCha20-Poly1305

• KeyAgreement

• ECDH with secp256r1 or secp384r1 curves

• X25519

• KeyFactory

• EC

• RSASSA-PSS

• X25519

• KeyGenerator

• AES with 256 bit key size

• ChaCha20

• KeyPairGenerator

• DH with 3072 bit key size

• EC with secp256r1 or secp384r1 curves

• RSA with 3072 bit key size

• RSASSA-PSS with 2048, 3072, 4096 bit key sizes

• X25519

• MessageDigest

• SHA-384

• Signature

• RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm

• SHA256WithECDSA with secp256r1 curve

• SHA384WithECDSA with secp384r1 curve

• SHA384WithRSA

• SSLContext

• TLSv1.3

Updated HSS/LMS Public Key Encoding

The X.509 encoded format for HSS/LMS public keys has been updated to align with the latest standard outlined in RFC 9708. Notably, the additional OCTET STRING wrapping around the public key value has been removed. For compatibility, public key encodings generated by earlier JDK releases are still recognized.

Update XML Security for Java to 3.0.5

The XML Signature implementation has been updated to Santuario 3.0.5. Support for four new SHA-3 based ECDSA SignatureMethod algorithms have been added: SignatureMethod.ECDSA_SHA3_224, SignatureMethod.ECDSA_SHA3_256, SignatureMethod.ECDSA_SHA3_384, and SignatureMethod.ECDSA_SHA3_512.

jpackage no longer includes service bindings by default for generated run-time images

Starting with JDK 25, jpackage will no longer include service bindings for a run-time image that it creates. Prior to JDK 25, jpackage would include service bindings for run-time images. As a result, the generated run-time images produced by jpackage might not include the same set of modules as it did in prior versions.

The previous behaviour can be achieved with jpackage of JDK 25 by adding the --bind-services jlink option to the default jlink options jpackage uses:

` jpackage [...] --jlink-options \ "--strip-native-commands --strip-debug --no-man-pages --no-header-files --bind-services" `

`java.util.zip.Inflater` and `java.util.zip.Deflater` Enhanced To Implement `AutoCloseable`

java.util.zip.Inflater and java.util.zip.Deflater now implement AutoCloseable and can be used with the try-with-resources statement. Applications could previously invoke the end() method to release the resources held by the Inflater/Deflater instance. Now, either the end() or the close() method can be invoked to do the same.

jlink --add-modules ALL-MODULE-PATH requires explicit --module-path argument

Starting with JDK 24, jlink --add-modules ALL-MODULE-PATH option will require users to set the module path via --module-path option. Prior to JDK 24, --add-modules ALL-MODULE-PATH without --module-path can be used to create an image with all JDK modules from $JAVA_HOME/jmods. In JDK 24, to create an image using ALL-MODULE-PATH, it is required to explicitly set --module-path.
To create an image with all JDK modules, use jlink --add-modules ALL-MODULE-PATH --add-modules $JAVA_HOME/jmods instead.