On Tue, 27 Jan 2026 07:42:19 GMT, Jaikiran Pai <[email protected]> wrote:

>> Can I please get a review of this change which proposes to remove the 
>> confusing "getsockopt" text from the exception reported on Windows when 
>> `SocketChannel.finishConnect()` raises an exception due to a failed 
>> `connect()`? 
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8376290 and as noted in 
>> that issue, this looks like an oversight when changes were done for 
>> https://bugs.openjdk.org/browse/JDK-8317603. Prior to that, on older 
>> versions the exception reported on Windows was:
>> 
>> 
>> java.net.ConnectException: Connection refused: no further information
>> 
>> 
>> With the current proposed changes in this PR, the exception will now be 
>> `java.net.ConnectException: Connection refused` which matches what we report 
>> on *nix platforms.
>> 
>> A new jtreg test has been added to reproduce the original text and verify 
>> the change. tier1, tier2 and tier3 continue to pass with this change.
>
> Jaikiran Pai has updated the pull request with a new target base due to a 
> merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains 10 additional 
> commits since the last revision:
> 
>  - merge latest from master branch
>  - fix assumption in test
>  - merge latest from master branch
>  - replace TestAbortedException with Assumptions.assumeTrue
>  - skip the test if the SocketChannel unexpectedly connects to the 
> destination address
>  - rename test to ConnectionRefusedMessage
>  - formatting
>  - add bug id to the test
>  - allow NULL for msg in NET_ThrowNew
>  - introduce test

test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 108:

> 106:         final InetAddress loopbackAddr = 
> InetAddress.getLoopbackAddress();
> 107:         // port 47 is reserved - there should be nothing listening on it
> 108:         InetSocketAddress destAddr = new InetSocketAddress(loopbackAddr, 
> 47);

a general comment on the dest port selections below, 47, 51, 61.
These are currently marked as reserved in the IANA port list, but if you look 
at the /etc/services file, on macos, you will see that there is a legacy 
assignment

As such, a comment in the test would be useful, such as,

// using ports 47, 51, 61 from the the IANA reserved port list, which
// are currently unassigned, on the assumption they will not used by
// a listening service

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29409#discussion_r2731678262

Reply via email to