Check whether TCPSocket#initialize supports open_timeout once and without exceptions

[eregon]

• See discussion in Replace Timeout.timeout with TCPSocket.open(open_timeout:) when available #224
• This check is known to work on at least CRuby, TruffleRuby and JRuby.
• Exceptions show up with ruby -d/$DEBUG == true and would show for every Net::HTTP instance.
• Fixes v0.8.0 is not working with JRuby #251

cc @osyoyu

[shioimm]

Thank you for addressing #251.
I read through the discussion in #224 (comment).
Initially, I wasn’t very enthusiastic about referring to Socket.tcp to check the arguments implemented in TCPSocket#initialize. However, considering the points raised in the discussion, it now seems likely that net-http may use Socket.tcp instead of TCPSocket.open in the future, so I’m beginning to think this direction seems reasonable.

[eregon]

Thanks for the review.
WDYT about having the constant in net-protocol? ruby/net-protocol#43
Is it OK to have net-http depend on the next release of net-protocol?
Because they both are default gems I'm not sure this is properly enforced, IIRC there used to be some problem with that.
Maybe @hsbt knows about that.

I think regardless of it, it's good to merge this PR soon and we can remove the slight duplication later on, because having the constant in net-protocol needs a release there, more coordination, and feels more risky.

[mame]

Why does JRuby hang with the original code? It looks like the original code doesn't have any major issue. Shouldn't this be treated as a JRuby bug, rather than net-http gem?

I don't think we need to worry about -d because it is practically unusable. And even newer Ruby versions that support open_timeout probably won't even raise an ArgumentError.

[osyoyu]

For the hanging issue (#251), I also believe that there is something to be fixed on the JRuby side.
Given that, I'm not against this change, as mentioned in #224 (comment).

For net-protocol, I agree with @eregon's standpoints in #252 (comment). If things are fixable within net-http, it'd be better to do so, at least as the first action.

[shioimm]

I found that in JRuby’s implementation, it seems that arguments other than connect_timeout are ignored, and select is called with no timeout. This may be related to the issue.
https://github.com/jruby/jruby/blob/9944d191ecfeecb02a56089d887b8499df1ce015/core/src/main/java/org/jruby/ext/socket/RubyTCPSocket.java#L97

[eregon]

Why does JRuby hang with the original code? It looks like the original code doesn't have any major issue. Shouldn't this be treated as a JRuby bug, rather than net-http gem?

TBH I did this change because I think the rescue ArgumentError approach is quite messy and somewhat brittle, e.g. if extra keyword arguments are ignored.
I happened to see the JRuby issue on the tracker after opening this PR and noticed this PR does seem to fix it.
I have no idea why but I also don't have time to investigate JRuby bugs.

FWIW it seems JRuby does raise an ArgumentError for:

$ ruby -v -rsocket -e 'TCPSocket.open("google.be", "80", "localhost", "44000", open_timeout: 10) {}'
jruby 10.0.2.0 (3.4.2) 2025-08-07 cba6031bd0 OpenJDK 64-Bit Server VM 21.0.8+9 on 21.0.8+9 +indy +jit [x86_64-linux]
ArgumentError: unknown keyword: :open_timeout
  initialize at org/jruby/ext/socket/RubyTCPSocket.java:198
  initialize at org/jruby/ext/socket/RubyTCPSocket.java:186
         new at org/jruby/RubyClass.java:1050
        open at org/jruby/RubyIO.java:1281
      <main> at -e:1

[eregon]

the original code doesn't have any major issue.

It has, an exception per Net::HTTP instance is a significant overhead, even more so on non-CRuby where getting a backtrace is more expensive.