Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources. Otherwise, you won't get any interoperability
with existing code, you need to deal with the fine points of concurrent
close, and you won't get proper thread interruption handling.
Right now, we use a custom, sockets-like class for UNIX domain sockets,
but it has the listed drawbacks (except that I think I worked around the
concurrent close issue in a similar way to the JVM).
(Obviously, an out-of-tree approach to new socket types would make it
easier to experiment.)
This is a good topic. For stream and datagram oriented protocols then it
would indeed be desirable to allow for communication domains other than
IP. In theory it should be possible to use a SocketImpl for this but
there are checks in the Socket API that reject non-InetSocketAddress
types (see 6402725). Furthermore, the Socket API itself has very IP
oriented methods so it doesn't gel well with non-IP protocols. As
regards an "out of tree" approach for experimentation - I'm not sure
that this would be straightforward as it would require hooks for
creating the socket and also when translating between the SocketAddress
implementation and the native socket address type.
FWIW, a while back I prototyped an "in tree" solution for SocketChannel.
The primary motive was to allow for Sockets Direct Protocol (which uses
IP addressing) and Unix Domain Sockets (which required a new
SocketAddress type). This isn't as extensible as what you might be
looking for but the API did allow the protocol (and optionally the
protocol family) to be specified when creating the SocketChannel. A
Protocols class allowed for protocol lookup (essentially a
getprotobyname equivalent).
-Alan.
