RELEASE NOTES: JDK 17.0.19

`TypeMirror` Changed to Provide Annotations for Types Loaded from Bytecode

The implementation of TypeMirror now provides access to annotations for types loaded from bytecode. Previously type annotations were not associated with types loaded from bytecode.

Annotation processors can access type annotations for elements using AnnotationMirror#getAnnotationMirrors, and the annotations will be included in the output of AnnotationMirror#toString.

Any programs that relied on annotations being omitted for elements loaded from the classpath should be updated to handle type annotations.

`GZIPInputStream` Will No Longer Use `InputStream.available()` to Check for the Presence of Concatenated GZIP Stream

The GZipInputStream read methods have been modified to remove the usage of InputStream::available() when determining if the stream contains a concatenated GZIP stream. These methods will now read any additional data in the underlying InputStream and check for the presence of a GZIP stream header.

Configurable New Session Tickets Count for TLSv1.3

A new system property, jdk.tls.server.newSessionTicketCount, sets the number of TLSv1.3 resumption tickets sent by a JSSE server per session. It can be set on the command line with -Djdk.tls.server.newSessionTicketCount=#, where # ranges from 0 to 10. The default is 1.

For more details, see Customizing JSSE.

Distrust TLS Server Certificates Anchored by Chunghwa Root Certificates and Issued After March 17, 2026

The JDK will stop trusting TLS server certificates issued after March 17, 2026 and anchored by Chunghwa root certificates, in line with similar plans announced by Google and Mozilla.

TLS server certificates issued on or before March 17, 2026 will continue to be trusted until they expire. Certificates issued after that date, and anchored by the Certificate Authority listed in the table below, will be rejected.

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below and the certificate has been issued after March 17, 2026.

An application will receive an exception with a message indicating the trust anchor is not trusted, for example:

` "TLS Server certificate issued after 2026-03-17 and anchored by a distrusted legacy Chunghwa root CA: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd." C=TW" `

The JDK can be configured to trust these certificates again by removing "CHUNGHWA_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Chunghwa Root certificates included in the JDK:

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server.

New Security Property jdk.crypto.disabledAlgorithms for Restricting Algorithms at the JCE layer

A new security property named jdk.crypto.disabledAlgorithms has been introduced to disable algorithms for JCE/JCA cryptographic services. Initially, this property only supports the Cipher, KeyStore, MessageDigest, and Signature services. This property is defined in the java.security file and initially no algorithms are disabled by default. However, this may change in the future. This security property can be overridden by a system property of the same name if applications need to re-enable algorithms.

See Disabled and Restricted Cryptographic Algorithms for more information.