In 1.2, RMI introduced a mechanism so that a remote object implementation
could specify the SocketType used for communication with that remote
object. The problem with the "java.rmi.server.SocketType" is that there is
no dynamic way of determining where the socket factory (that knows how to
create sockets of the specific socket type) should be downloaded from. We
have specified a flexible lookup mechanism for determining the socket
factory corresponding to a specific type, but this requires that socket
factories be installed on the client, a requirement that makes the SocketType
completely unusable when used from an applet in a browser.

The original idea behind the SocketType was to allow different socket
protocols to be defined (e.g., "SSL") and have an installed socket
factory delegate to whatever implementation of the protocol type was
available. This scheme requires cooperation from browser vendors to
both get them involved in defining the protocol types and to make
sure that they have installed factories that handle the requisite types.

We believed that SocketType was advantageous since multiple implementations
for a specific protocol could exist, but we believe that getting vendors
to agree on the set of protocols to be supported along with requiring them
to have socket factories installed that handle the protocols is almost
next to impossible (and would require resources that we just don't have).

We propose an alternate mechanism that would allow the socket factory
to be downloaded to the client so that the protocol chosen by the
socket factory can be used. This allows the use of alternate socket
types in RMI 1.2 to be effectively used immediately in applets deployed
on a 1.2 VM.

We have been beaten up heavily by customers in the past because applets
cannot set the global socket factory that RMI uses since they want to
use custom socket types. Allowing downloadable socket factories addresses
a huge customer need.