Consider the case where a java.nio.channels.SocketChannel has registered with a java.nio.channels.Selector and has expressed interest in SelectionKey.OP_CONNECT. The connect() is then called on the SocketChannel. The server (peer) refuses the connection attempt for whatever reason. The selector then wakes up and delivers this as a selected key for the unsuccessful connect which the application then processes by calling SocketChannel.finishConnect(). That leads to the following exception on Windows:

java.net.ConnectException: Connection refused: getsockopt
    at java.base/sun.nio.ch.Net.pollConnect(Native Method)
    at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:642)
    at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:1043)


The exception itself is understandable because the connect was actually rejected by the peer. However, what's confusing (only on Windows), is the mention of getsockopt in that exception message. Looking at the code in the JDK implementation of Java_sun_nio_ch_Net_pollConnect on Windows, I think that's a typo here https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/libnio/ch/Net.c#L721-L737. What that code is doing is determining the error that caused the connection attempt to have failed. To do that, it checks the value of SO_ERROR socket option and sets it in optError. It then wants to raise/throw that underlying connect error to the application so does this:

else if (optError != NO_ERROR) {
    NET_ThrowNew(env, optError, "getsockopt");
}

The last param to the NET_ThrowNew is the "message" that will be included in the Exception instance that gets raised. Passing "getsockopt" there looks like a copy/paste issue - it's the connect operation that has failed and not getsockopt.

Ideally, the exception that is raised should just be "java.net.ConnectException: Connection refused", just like what we see on *nix.