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
