In JDK 1.1, the "java.net.Socket" and "java.net.ServerSocket" classes
were made subclassable to support other kinds of socket implementations.
That was specifically intended to include native implementations of
things like SSL and IPX/SPP streams.

Within JavaSoft we tested the sufficiency of those API changes only by
using them to create a pure Java SSL package. (Well, some crypto code
is patented so we can't legally ship Java versions -- but that's really
not relevant to this bug.)


The problem is that for implementations that use their own networking
code (native) rather than the TCP support in the JDK, they MUST use one
of the existing "ServerSocket" constructors -- each of which allocates
a passive TCP server socket on some port. This forces wasteful use of
network resources, and on some platforms can be seriously detrimental.

In particular, this makes it hard to use validated/proven implementations
of existing protocol stacks, when they happen to (a) be in native code
and (b) not be appropriate for use through the "socket impl factory" scheme.



Name: skT88420 Date: 05/05/99


The default constructor of ServerSocket is private.
The documentation
(http://www.javasoft.com/products/jdk/1.2/docs/guide/net/extendingSocks.html)
states that it should be protected.
The documentation reasoned that it should be protected to
allow extending ServerSocket.

In addition to making the default constructor protected, I
think there should be another protected constructor in the
form of ServerSocket(SocketImpl), just like Socket.
This would allow derived ServerSockets that don't use TCP.
(Review ID: 57851)
======================================================================