On Mon, 14 Sep 2026 08:39:33 GMT, Lee Jiwon <[email protected]> wrote:
>> Disable `IP_TOS` support by default in the JDK's default `ServerSocket` >> implementation. Applications can restore support with >> `-Djdk.net.ServerSocket.IP_TOS=true` on the JVM command line. >> >> The `jdk.net.Sockets` option sets are derived from socket instances, >> exposing previously omitted datagram options. `IP_TOS` support on `Socket` >> and `DatagramSocket` is unchanged. >> >> Testing on macOS/aarch64 at `828e5c2b7e76`: >> >> - Affected socket-option tests passed, including five `SupportedOptions` >> configurations. >> - Tier 2 reported five locale failures also seen on baseline, the previously >> observed `UdpTest` timeout, a docs link-check failure due to missing files, >> and a `CreateCoredumpOnCrash` failure due to the core dump limit. >> - `PromiscuousIPv6`, `SSLSocketExplorer`, and `MultiNSTClient` failed or >> timed out in Tier 2; all passed on individual reruns. >> >> Linux and Windows test suites were not run. >> >> Release note: [JDK-8392329](https://bugs.openjdk.org/browse/JDK-8392329) >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Lee Jiwon has updated the pull request incrementally with one additional > commit since the last revision: > > 8392151: Address review comments I don't object to disable IP_TOS as proposed but I'm not sure about the motivation. Did you jump on this issue because you were puzzled to see IP_TOS in the list or did you just spot an open issue in JBS on this topic? As regards jdk.net.Sockets. This JDK-specific API was introduced as a stop-gap because the setOption/getOption/supportedOptions were only added to the socket classes in JDK 9. Applications running on older JDK releases were screaming for a means to set JDK-specific socket options, which they could do with SocketChannel but not Socket. There is no reason to use jdk.net.Sockets in new code. Anything use that API should be migrating to the standard API. At some point we need to deprecate Sockets for removal. Right now, all methods are deprecated and supportedOptions is deprecated for removal. As regards running out of file descriptors. You are right that creating an unbound socket doesn't help as invoking supportedOptions will create the underlying SocketImpl and thus could fail if exhausted. I wouldn't be too concerned with that issue. As jdk.net.Sockets is a legacy class, supportedOptions is deprecated for removal, then I think it's okay for it to not cache. It would be okay if each call to supportedOptions created a socket, invoked the socket's supportedOptions method, and closed the socket. It's not performance critical. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32808#issuecomment-5676343203
