[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-net-dev
Subject:    Re: Implementing a custom SocketImpl
From:       Chris Hegarty <chris.hegarty () oracle ! com>
Date:       2019-03-23 9:07:20
Message-ID: F0F44FEB-5D72-498C-9289-620E56BC6981 () oracle ! com
[Download RAW message or body]

Jared,

As Alan mentioned, SocketImpl was designed 20+ years ago and has not
kept pace with other areas of the platform. Mainly because it has not
been used all that much. As part of JEP 337 [1] a decision was made to
NOT simply provide a RDMA socket impl for the sockets part of this
work, but rather to subclass all three, j.n.Socket, j.n.ServerSocket,
and j.n.SocketImpl, and take control of their construction ( through
factories ). There are just too many entanglements between these
classes now, and unraveling them without all the history and knowledge
of their original purpose and intent is risky and time consuming.

The current work in this area, that Alan and others are doing, is really
just the minimum possible to lay the foundations for a replacement,
loom-friendly, platform socket impl, and address some small amount of
technical debt along the way. In general, we're not investing in
improving support for plugging in SocketImpls. Our recommendation is to
provide custom socket implementations in a similar way to what is being
done in JEP 337.

If it makes sense for the library or code that you are using to allow
other socket implementations ( which is what you want to do ), then
maybe submit a pull-request to that project to add support for a socket
factory. Socket Factory is a better alternative than trying to provide
a custom socket impl through setSocketImplFactory.

I understand that this may not be the answer that you were hoping for,
but it is highly unlikely that we're going to start investing in this
area any time soon.

-Chris.

[1] https://openjdk.java.net/jeps/337

> On 20 Mar 2019, at 16:28, Lundell, Jared <lundell@amazon.com> 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? 
> Thanks,
> Jared
> 
> PS I just joined the net-dev mailing list, so there may be some historical context \
> I've missed. 
> [1] https://mail.openjdk.java.net/pipermail/net-dev/2019-March/012218.html
> [2] http://cr.openjdk.java.net/~alanb/8220493/0/webrev/
> [3] http://openjdk.java.net/jeps/8218559
> 


[prev in list] [next in list] [prev in thread] [next in thread]