On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket >> and java.net.Socket classes? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes >> currently refer to the legacy `java.net.SocketOptions` interface and instead >> should be refering to the newer `java.net.StandardSocketOptions` class. The >> commit in this PR updates such references. This change intentionally doesn't >> do any code changes to use the `StandardSocketOptions` class - that can be >> done separately if desired at a later point (after testing for any >> compatibility issues). Finally, there are a few places in ServerSocket and >> Socket documentation which will continue to refer to java.net.SocketOptions >> legacy interface because few of the options aren't available in >> StandardSocketOptions class (for example, `SO_TIMEOUT`). >> >> I ran `make docs-image` locally with this change and the generated doc looks >> OK to me. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > separate links for SocketImplFactory and createSocketImpl @jaikiran the only reservation I have is that the new wording makes it look like the default implementation of `ServerSocket` methods is going to call `SocketImpl::getOption(SocketOption<>)` while in fact it still calls `SocketImpl::getOption(SocketOptions)`. But if @AlanBateman is good with that I am good as well. Maybe the fact that the two SocketImpl methods have equivalent results and that the implementation still call the legacy one should be spelled out in a public comment in the JBS issue? I am worrying about possible implication with JCK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18646#issuecomment-2044371733