it looks like all it does is to delegate the call to java.net.SocketImpl.connect(SocketaAddress, int).
which is an abstract method of the SocketImpl
class.
The subclass actually implementing it (the system-default SocketImpl
implicitly retrieved from SocketImplFactory.createSocketImpl()
in the Socket
constructor) in turn relies on a native method, so it's not possible to know the inaccuracy in a platform-independent way.
-- EDIT (response to comment)
If not using a Socket
subclass that specifies a custom SocketImpl
via the protected Socket(SocketImpl impl)
constructor, the standard Socket
instance created by the Socket()
constructor uses a SocksSocketImpl
(which in turn extends PlainSocketImpl
).
SocksSocketImpl.connect(SocketAddress address, int timeout)
calls
super.connect(SocketAddress address, int timeout)
(PlainSocketImpl.connect(SocketAddress address, int timeout)
),
which in turn calls
PlainSocketImpl.connectToAddress(InetAddress address, int port, int timeout)
,
which in turn calls
PlainSocketImpl.doConnect(InetAddress address, int port, int timeout)
,
which in turn calls
PlainSocketImpl.socketConnect(InetAddress address, int port, int timeout)
,
which is a private native method, and we don't know what's inside :)
So no, we're not relying upon Object.wait
.
--
See http://jcs.mobile-utopia.com/jcs/18846_PlainSocketImpl.java and http://jcs.mobile-utopia.com/jcs/31401_SocksSocketImpl.java for source code