RELEASE NOTES FOR: 17.0.11
====================================================================================================

Notes generated: Sat Dec 09 06:32:25 CET 2023

Hint: Prefix bug IDs with https://bugs.openjdk.org/browse/ to reach the relevant JIRA entry.

JAVA ENHANCEMENT PROPOSALS (JEP):

  None.

RELEASE NOTES:

core-libs/java.lang:

    JDK-8307990: 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) ```     


ALL FIXED ISSUES, BY COMPONENT AND PRIORITY:

client-libs/2d:
  (P3) JDK-8318951: Additional negative value check in JPEG decoding
  (P3) JDK-8313643: Update HarfBuzz to 8.2.2

client-libs/java.awt:
  (P3) JDK-8316030: Update Libpng to 1.6.40

client-libs/javax.sound:
  (P3) JDK-8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library
  (P3) JDK-8301310: The SendRawSysexMessage test may cause a JVM crash

client-libs/javax.swing:
  (P2) JDK-8300269: The selected item in an editable JComboBox with titled border is not visible in Aqua LAF
  (P4) JDK-8290399: [macos] Aqua LAF does not fire an action event if combo box menu is displayed
  (P4) JDK-7132796: [macosx] closed/javax/swing/JComboBox/4517214/bug4517214.java fails on MacOS
  (P4) JDK-8054572: [macosx] JComboBox paints the border incorrectly
  (P4) JDK-7148092: [macosx] When Alt+down arrow key is pressed, the combobox popup does not appear.
  (P4) JDK-8286846: test/jdk/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on mac aarch64

core-libs/java.lang:
  (P3) JDK-8307990: jspawnhelper must close its writing side of a pipe before reading from it
  (P3) JDK-8311645: Memory leak in jspawnhelper spawnChild after JDK-8307990

core-libs/java.net:
  (P3) JDK-8301787: java/net/httpclient/SpecialHeadersTest failing after JDK-8301306
  (P4) JDK-8301306: java/net/httpclient/* fail with -Xcomp
  (P4) JDK-8269258: java/net/httpclient/ManyRequestsLegacy.java failed with connection timeout

core-libs/java.nio:
  (P4) JDK-8317603: Improve exception messages thrown by sun.nio.ch.Net native methods (win)

core-libs/java.util.concurrent:
  (P4) JDK-8317960: [17u] Excessive CPU usage on AbstractQueuedSynchronized.isEnqueued

core-svc/debugger:
  (P4) JDK-8318736: com/sun/jdi/JdwpOnThrowTest.java failed with "transport error 202: bind failed: Address already in use"

core-svc/java.lang.management:
  (P4) JDK-8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM

hotspot/compiler:
  (P4) JDK-8320363: ppc64 TypeEntries::type_unknown logic looks wrong, missed optimization opportunity
  (P4) JDK-8302149: Speed up compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java

hotspot/gc:
  (P1) JDK-8292946: GC lock/jni/jnilock001 test failed "assert(gch->gc_cause() == GCCause::_scavenge_alot || !gch->incremental_collection_failed()) failed: Twice in a row"
  (P2) JDK-8308043: Deadlock in TestCSLocker.java due to blocking GC while allocating
  (P4) JDK-8316418: containers/docker/TestMemoryWithCgroupV1.java get OOM killed with Parallel GC
  (P4) JDK-8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"

hotspot/jfr:
  (P3) JDK-8295274: HelidonAppTest.java fails "assert(event->should_commit()) failed: invariant" from compiled frame"
  (P3) JDK-8287832: jdk/jfr/event/runtime/TestActiveSettingEvent.java failed with "Expected two batches of Active Setting events"
  (P3) JDK-8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state

hotspot/jvmti:
  (P4) JDK-8319961: JvmtiEnvBase doesn't zero _ext_event_callbacks

hotspot/runtime:
  (P4) JDK-8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074
  (P4) JDK-8312434: SPECjvm2008/xml.transform with CDS fails with "can't seal package nu.xom"
  (P4) JDK-8299494: Test vmTestbase/nsk/stress/except/except011.java failed: ExceptionInInitializerError: target class not found

infrastructure:
  (P4) JDK-8320885: Bump update version for OpenJDK: jdk-17.0.11

security-libs/javax.net.ssl:
  (P4) JDK-8310106: sun.security.ssl.SSLHandshake.getHandshakeProducer() incorrectly checks handshakeConsumers

xml/javax.xml.validation:
  (P3) JDK-8298087: XML Schema Validation reports an required attribute twice via ErrorHandler
  (P4) JDK-8283994: Make Xerces DatatypeException stackless