On Sun, 13 Sep 2026 14:12:59 GMT, Alan Bateman <[email protected]> wrote:
>> On macOS/aarch64, deriving the sets from socket instances adds five options >> for `DatagramSocket` (`IP_DONTFRAGMENT`, `SO_BROADCAST`, and the three >> `IP_MULTICAST_*` options), and two for `MulticastSocket` (`IP_DONTFRAGMENT` >> and `SO_BROADCAST`). >> >> Should I include these changes in this PR and update the CSR, or derive only >> the `ServerSocket` set here and handle the others separately? > > Right, the (depreacted) jdk.net.Sockets.supportedOptions method has a > hardcoded lists of options that is out of date. The spec for these method > allows the set to include non-standard sockets options. So yes, a side effect > is that it "fixes" the issue. I used new DatagramSocket(null) to avoid binding an ephemeral port. I also found an initialization failure when file descriptors are exhausted. On macOS/aarch64, I compared the old and new Sockets.java using --patch-module with the same JDK build, limiting the test process to RLIMIT_NOFILE=256. On an existing TCP socket, direct setOption and the old Sockets.setOption succeeded. The new Sockets.setOption threw IOError during datagram socket creation. After releasing the file descriptors, retrying threw NoClassDefFoundError. Would it make sense to initialize the option sets in a lazy holder, so that this failure does not affect the set/get methods? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32808#discussion_r4011628255
