Implementing a custom SocketImpl

[Alan Bateman]

On 20/03/2019 16:28, Lundell, Jared wrote:
> I have a use case where I need to implement a custom SocketImpl class and I've run into some difficulty caused by the current design of SocketImpl and the related classes in OpenJDK.  My use case is implementing a custom proxy protocol, similar in spirit to what SocksSocketImpl does but using a different wire protocol.  I need to be able to swap this proxy in underneath some existing code that I can't modify, which is why I think a SocketImpl is the appropriate solution rather than a SocketFactory (which would be much easier if I could modify the code in question).
>   
> SocketImpl is a public class, so I think I'm fairly safe in assuming it's intended as an extension point for application authors, but in practice it seems very difficult to actually extend.  Since I'm trying to accomplish something very similar to what SocksSocketImpl does I'd like to take the same approach that it and HttpConnectSocketImpl use of delegating all of the OS interactions to the base PlainSocketImpl class and just adding the customizations I need on top.  However, I can't extend PlainSocketImpl the way those other classes do because it is package-private and I can't create new classes in java.net.  Encapsulating a PlainSocketImpl doesn't really seem viable either since all of the methods are also protected or package-private.  The alternatives I can see are to either implement a SocketImpl completely from scratch (including all the native code) or to resort to classloader hacks to be able to add a class to java.net which extends PlainSocketImpl.  Neither of those are particularly appealing.
>   
> I was going to ask whether it would be reasonable to make PlainSocketImpl public, but reading through the net-dev archives[1] I discovered that there's some refactoring[2] of SocketImpl that's happening right now to prepare for Project Loom related work[3].  That change is introducing DelegatingSocketImpl and PlatformSocketImpl classes and changes SocksSocketImpl and HttpConnectSocketImpl to extend DelegatingSocketImpl rather than PlainSocketImpl.  I'd love to be able to extend DelegatingSocketImpl for my use case, but it's package-private too, nor does there appear to be a way to get a PlatformSocketImpl.
>   
> Is there any way that we could make it easier to implement a custom SocketImpl (or am I missing some other possible approach)?  If so, would it be reasonable to make DelegatingSocketImpl public and introduce a DefaultSocketImplFactory that can be used to construct a PlatformSocketImpl?
>
SocketImpl is a JDK 1.0 era mechanism. You are right that it's very 
difficult to implement, partly because it requires a complete 
implementation with native code, partly because SocketImpl is very 
under-specified.

The built-in SocketImpls are not public and not intended to be used 
directly. It wouldn't be wrong to introduce a way to create custom 
SocketImplFactory with a reference to a SocketImplFactory that creates 
platform SocketImpl instances - that would amount to providing a way to 
interpose or wrap instances of the platform SocketImpl. The JDK has 
something like this to allow a custom file system provider interpose on 
the built-in file system provider. However, in the case of SocketImpl 
then it would be opening a basket of snakes that would require 
significant specification and security work to contain. So I don't think 
we want to go there.

That said, one approach to explore is changing "new 
Socket(Proxy.NO_PROXY)" to return a Socket with a platform SocketImpl. 
That constructor was added in Java SE 1.5 and I believe, but not 
certain, that the intention was for NO_PROXY to not use a custom 
SocketImpl. If that were changed then it would mean that custom 
SocketImpls could create a Socket to delegate to. They can do this now 
except for the case that Socket.setSocketImplFactory has been called to 
configure the system-wide SocketImplFactory, which I think is what you 
are trying to do.

-Alan