SocketImpl is an abstract class. PlainSocketImpl extends it and has all the
native methods in it to open, read, and write to sockets, but PlainSocketImpl
is a package-protected class. That means that I cannot declare, e.g., a new FirewallSocketImpl (to tunnel out through firewalls) that extends
PlainSocketImpl unless I put my FirewallSocketImpl class in java.net, but
that's the only way I can get access to the native methods that actually do all
the work of accessing the native socket. Unless I can extend PlainSocketImpl,
I can't do anything useful with subclasses of SocketImpl that want to slightly
modify the behavior of standard sockets. And I certainly don't think I should
have to duplicate the native code and provide a native library for this.

The only way to do anything useful with Sockets is to extend Socket itself, so
that it can create the PlainSocketImpl for you, but that requires that all
users need to know to use your special FirewallSocket instead of the regular
Socket (is that why Socket was changed from being a final class?). I'd rather
just install a SocketImplFactory that handles all the details of tunneling out
of firewalls, etc., and thereby be able to take existing code that assumes a
highly connected network and allow it to run w/o change. That seems to me to
be the intention of SocketImplFactory.