There are package-private dependencies between (Server)Socket and
SocketImpl that result in complications and difficulties when writing a
custom SocketImpl.

SocketImpl has two package-private methods ( setSocket and
setServerSocket ) for setting the (Server)Socket that the impl is
associated with. There are also a pair of getters, but these are not
used by either of Socket or ServerSocket. The setters add a cyclic
dependency between the instances so that the socket may invoke methods
of the impl, and the impl may invoke methods of the socket. This of
course causes issues for custom socket impls outside of the java.net
package.

FTR these package-private entanglements were introduced to resolve a
compatibility issue with "old" ( pre unconnected sockets ) style socket
impls back in 2001, see JDK-4468846 and JDK-4468805.

Some advise that may help workaround this issue:

1) Take control of construction.

  In many cases a suitable factory may be used to create and return an
  instance of a (Server)Socket that is backed by a custom impl. Use one
  of the protected constructors that accepts a SocketImpl. That way
  the impl given to either the ServerSocket or Socket constructor will
  have knowledge a priori whether, or not, the impl will be associated
  with a client socket or server socket. Create a separate subclass for
  each of client-socket-impl and server-socket-impl.

2) Override SocketImpl getOption, setOption, and supportedOptions.

  Given 1 above, custom client or server socket impls may return an
  appropriate set of supported socket options from the supportedOptions
  method. Similarly, get and set Options can validate the given option
  from said set.
    This is necessary as the default SocketImpl code that deals with socket
  options makes use of the value that may have been set by the package-
  private set(Server)Socket method, which is not available to custom
  impls.