RELEASE NOTES: JDK 17.0.11

`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.

Update XML Security for Java to 3.0.3

The XML Signature implementation has been updated to Santuario 3.0.3. Support for four new SHA-3 based RSA-MGF1 SignatureMethod algorithms have been added: SignatureMethod.SHA3_224_RSA_MGF1, SignatureMethod.SHA3_256_RSA_MGF1, SignatureMethod.SHA3_384_RSA_MGF1, and SignatureMethod.SHA3_512_RSA_MGF1.

Update XML Security for Java to 3.0.3

The XML Signature implementation has been updated to Santuario 3.0.3. Support for four new SHA-3 based RSA-MGF1 signature methods have been added: SHA3_224_RSA_MGF1, SHA3_256_RSA_MGF1, SHA3_384_RSA_MGF1, and SHA3_512_RSA_MGF1. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK update releases, they may be represented as string literals in order to be functionally equivalent. SHA-3 hash algorithm support was delivered to JDK 9 via JEP 287. Releases earlier than that may use third party security providers.

Update XML Security for Java to 3.0.2

The XML Signature implementation has been updated to Santuario 3.0.2. Support for the following EdDSA signatures has been added: ED25519 and ED448. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK Update releases, they may be represented as string literals in order to be functionally equivalent. The JDK supports EdDSA since JDK 15. Releases earlier than that may use 3rd party security providers. One other difference is that the JDK still supports the here() function by default. However, we recommend avoiding the use of the here() function in new signatures and replacing existing signatures that use the here() function. Future versions of the JDK will likely disable, and eventually remove, support for this function, as it cannot be supported using the standard Java XPath API. Users can now disable the here() function by setting the security property jdk.xml.dsig.hereFunctionSupported to "false".

Update XML Security for Java to 3.0.2

The XML Signature implementation has been updated to Santuario 3.0.2. The main, new feature is support for EdDSA. One difference is that the JDK still supports the here() function by default. However, we recommend avoiding the use of the here() function in new signatures and replacing existing signatures that use the here() function. Future versions of the JDK will likely disable, and eventually remove, support for this function, as it cannot be supported using the standard Java XPath API. Users can now disable the here() function by setting the security property jdk.xml.dsig.hereFunctionSupported to "false".

Fixed Indefinite `jspawnhelper` Hangs

Since JDK 13, executing commands in a sub-process uses the so-called POSIX_SPAWN launching mechanism (that is, -Djdk.lang.Process.launchMechanism=POSIX_SPAWN) by default on Linux. In cases where the parent JVM process terminates abnormally before the handshake between the JVM and the newly created jspawnhelper process has completed, jspawnhelper can hang indefinitely in JDK 13 to JDK 20. This issue is fixed in JDK 21. The issue was especially harmful if the parent process had open sockets, because in that case, the forked jspawnhelper process will inherit them and keep all the corresponding ports open, effectively preventing other processes from binding to them.

This misbehavior has been observed with applications which frequently fork child processes in environments with tight memory constraints. In such cases, the OS can kill the JVM in the middle of the forking process leading to the described issue. Restarting the JVM process after such a crash will be impossible if the new process tries to bind to the same ports as the initial application because they will be blocked by the hanging jspawnhelper child process.

The root cause of this issue is jspawnhelper's omission to close its writing end of the pipe, which is used for the handshake with the parent JVM. It was fixed by closing the writing end of the communication pipe before attempting to read data from the parent process. This way, jspawnhelper will reliably read an EOF event from the communication pipe and terminate once the parent process dies prematurely.

A second variant of this issue could happen because the handshaking code in the JDK didn't handle interrupts to write(2) correctly. This could lead to incomplete messages being sent to the jspawnhelper child process. The result is a deadlock between the parent thread and the child process which manifests itself in a jspawnhelper process being blocked while reading from a pipe and the following stack trace in the corresponding parent Java process: ` java.lang.Thread.State: RUNNABLE at java.lang.ProcessImpl.forkAndExec(java.base@17.0.7/Native Method) at java.lang.ProcessImpl.<init>(java.base@17.0.7/ProcessImpl.java:314) at java.lang.ProcessImpl.start(java.base@17.0.7/ProcessImpl.java:244) at java.lang.ProcessBuilder.start(java.base@17.0.7/ProcessBuilder.java:1110) at java.lang.ProcessBuilder.start(java.base@17.0.7/ProcessBuilder.java:1073) `

AWT SystemTray API Is Not Supported on Most Linux Desktops

The java.awt.SystemTray API is used for notifications in a desktop taskbar and may include an icon representing an application. On Linux, the Gnome desktop's own icon support in the taskbar has not worked properly for several years due to a platform bug. This, in turn, has affected the JDK's API, which relies upon that.

Therefore, in accordance with the existing Java SE specification, java.awt.SystemTray.isSupported() will return false where ever the JDK determines the platform bug is likely to be present.

The impact of this is likely to be limited since applications always must check for that support anyway. Additionally, some distros have not supported the SystemTray for several years unless the end-user chooses to install non-bundled desktop extensions.

Added Certainly R1 and E1 Root Certificates

The following root certificates have been added to the cacerts truststore: ``` + Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US

• Certainly
• certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US ```