The legacy SocketImpl mechanism has a number of issues that surface when you attempt to replace PlainSocketImpl with an alternative implementation or configure the JDK to use an alternative implementation (via the system property or the setSocketImplFactory​ methods).

1. accept(SocketImpl) assumes that the impl can accept any SocketImpl implementation. If one of Socket.setSocketImplFactory orServerSocket.setSocketImplFactory (but not both) are used to set a SocketImplFactory then you end up with a mismatch or ClassCastException issues when cast to the specific impl. PlainSocketImpl avoids this, partly because it accessed the impl fields from JNI (without access restrictions) and partly because it doesn't need the PSI state accept(SocketImpl). The summary is that you can't have a ServerSocket based on one impl type and have it accept a connection where the Socket is based on a different impl type.

2. ServerSocket implAccept(Socket) creates several issues for SocketImpl implementations. It's not clear if the given Socket's impl has to be wired to the accepted connection or whether the Socket's impl can be replaced with a new impl for the accepted connection. There are many other issues around this, particularly with any socket options that may have been set on the Socket before implAccept is called.

3. A SocketImpl is created without a connection to its enclosing Socket or ServerSocket. This leads to confusion with the "address" field and whether the impl should set it to the local or remote address. It creates problems for the SO_REUSEADDR socket option too as the impl does not know whether to enable this socket option or not. Another issue is the streams returned by the impl's getInputStream and getOutputStream methods. If close is invoked then it should close the enclosing Socket or ServerSocket but this is not possible when the impl does not have a connection.

4. Many of the methods defined by SocketImpl, and also java.net.SocketOptions, have incomplete javadoc and don't specific several exceptions, e.g. setOption(int, Object) does not specify how invalid parameters are handled. PlainSocketImpl will throw SocketException in some cases, UnsupportedOperationException in others, and InvalidArgumentException for values out of range.
The SocketImpl shutdownInput and shutdownOutput methods are another example, in this case the spec doesn't say how the methods should behave if the socket is not connected. Also they do no specify how they behalf when already shutdown. Another example is sendUrgentData which does not specify anything about how it should behave when the impl is closed. There are a dozen or more other small issues SocketImpl spec.