An ExportException is a RemoteException
thrown if an attempt to export a remote object fails.  A remote object is
exported via the constructors and exportObject methods of
java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable.

Deprecated.
no replacement

Deprecated.
no replacement

An ObjID is used to identify a remote object exported
to an RMI runtime.  When a remote object is exported, it is assigned
an object identifier either implicitly or explicitly, depending on
the API used to export.

The ObjID() constructor can be used to generate a unique
object identifier.  Such an ObjID is unique over time
with respect to the host it is generated on.

The ObjID(int) constructor can be used to create a
`well-known` object identifier.  The scope of a well-known
ObjID depends on the RMI runtime it is exported to.

An ObjID instance contains an object number (of type
long) and an address space identifier (of type
UID).  In a unique ObjID, the address space
identifier is unique with respect to a given host over time.  In a
well-known ObjID, the address space identifier is
equivalent to one returned by invoking the UID.UID(short)
constructor with the value zero.

If the system property java.rmi.server.randomIDs
is defined to equal the string `true` (case insensitive),
then the ObjID() constructor will use a cryptographically
strong random number generator to choose the object number of the
returned ObjID.

Deprecated.
no replacement

Deprecated.
no replacement.

The RemoteObject class implements the
java.lang.Object behavior for remote objects.
RemoteObject provides the remote semantics of Object by
implementing methods for hashCode, equals, and toString.

An implementation of the InvocationHandler interface for
use with Java Remote Method Invocation (Java RMI).  This invocation
handler can be used in conjunction with a dynamic proxy instance as a
replacement for a pregenerated stub class.

Applications are not expected to use this class directly.  A remote
object exported to use a dynamic proxy with UnicastRemoteObject
or Activatable has an instance of this class as that proxy's
invocation handler.

RemoteRef represents the handle for a remote object. A
RemoteStub uses a remote reference to carry out a
remote method invocation to a remote object.

The RemoteServer class is the common superclass to server
implementations and provides the framework to support a wide range
of remote reference semantics.  Specifically, the functions needed
to create and export remote objects (i.e. to make them remotely
available) are provided abstractly by RemoteServer and
concretely by its subclass(es).

Deprecated.
Statically generated stubs are deprecated, since
 stubs are generated dynamically. See UnicastRemoteObject
 for information about dynamic stub generation.

RMIClassLoader comprises static methods to support
dynamic class loading with RMI.  Included are methods for loading
classes from a network location (one or more URLs) and obtaining
the location from which an existing class should be loaded by
remote parties.  These methods are used by the RMI runtime when
marshalling and unmarshalling classes contained in the arguments
and return values of remote method calls, and they also may be
invoked directly by applications in order to mimic RMI's dynamic
class loading behavior.

The implementation of the following static methods



loadClass(URL,String)
loadClass(String,String)
loadClass(String,String,ClassLoader)
loadProxyClass(String,String[],ClassLoader)
getClassLoader(String)
getClassAnnotation(Class)



is provided by an instance of RMIClassLoaderSpi, the
service provider interface for those methods.  When one of the
methods is invoked, its behavior is to delegate to a corresponding
method on the service provider instance.  The details of how each
method delegates to the provider instance is described in the
documentation for each particular method.

The service provider instance is chosen as follows:



If the system property
java.rmi.server.RMIClassLoaderSpi is defined, then if
its value equals the string `default`, the provider
instance will be the value returned by an invocation of the getDefaultProviderInstance() method, and for any other value, if
a class named with the value of the property can be loaded by the
system class loader (see ClassLoader.getSystemClassLoader())
and that class is assignable to RMIClassLoaderSpi and has a
public no-argument constructor, then that constructor will be
invoked to create the provider instance.  If the property is
defined but any other of those conditions are not true, then an
unspecified Error will be thrown to code that attempts
to use RMIClassLoader, indicating the failure to
obtain a provider instance.

If a resource named
META-INF/services/java.rmi.server.RMIClassLoaderSpi is
visible to the system class loader, then the contents of that
resource are interpreted as a provider-configuration file, and the
first class name specified in that file is used as the provider
class name.  If a class with that name can be loaded by the system
class loader and that class is assignable to RMIClassLoaderSpi and has a public no-argument constructor, then
that constructor will be invoked to create the provider instance.
If the resource is found but a provider cannot be instantiated as
described, then an unspecified Error will be thrown to
code that attempts to use RMIClassLoader, indicating
the failure to obtain a provider instance.

Otherwise, the provider instance will be the value returned by
an invocation of the getDefaultProviderInstance() method.

RMIClassLoaderSpi is the service provider interface for
RMIClassLoader.

In particular, an RMIClassLoaderSpi instance provides an
implementation of the following static methods of
RMIClassLoader:



RMIClassLoader.loadClass(URL,String)
RMIClassLoader.loadClass(String,String)
RMIClassLoader.loadClass(String,String,ClassLoader)
RMIClassLoader.loadProxyClass(String,String[],ClassLoader)
RMIClassLoader.getClassLoader(String)
RMIClassLoader.getClassAnnotation(Class)



When one of those methods is invoked, its behavior is to delegate
to a corresponding method on an instance of this class.
The details of how each method delegates to the provider instance is
described in the documentation for each particular method.
See the documentation for RMIClassLoader for a description
of how a provider instance is chosen.

An RMIClientSocketFactory instance is used by the RMI runtime
in order to obtain client sockets for RMI calls.  A remote object can be
associated with an RMIClientSocketFactory when it is
created/exported via the constructors or exportObject methods
of java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable .

An RMIClientSocketFactory instance associated with a remote
object will be downloaded to clients when the remote object's reference is
transmitted in an RMI call.  This RMIClientSocketFactory will
be used to create connections to the remote object for remote method calls.

An RMIClientSocketFactory instance can also be associated
with a remote object registry so that clients can use custom socket
communication with a remote object registry.

An implementation of this interface should be serializable and
should implement Object.equals(java.lang.Object) to return true when
passed an instance that represents the same (functionally equivalent)
client socket factory, and false otherwise (and it should also
implement Object.hashCode() consistently with its
Object.equals implementation).

An RMIFailureHandler can be registered via the
RMISocketFactory.setFailureHandler call. The
failure method of the handler is invoked when the RMI
runtime is unable to create a ServerSocket to listen
for incoming calls. The failure method returns a boolean
indicating whether the runtime should attempt to re-create the
ServerSocket.

An RMIServerSocketFactory instance is used by the RMI runtime
in order to obtain server sockets for RMI calls.  A remote object can be
associated with an RMIServerSocketFactory when it is
created/exported via the constructors or exportObject methods
of java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable .

An RMIServerSocketFactory instance associated with a remote
object is used to obtain the ServerSocket used to accept
incoming calls from clients.

An RMIServerSocketFactory instance can also be associated
with a remote object registry so that clients can use custom socket
communication with a remote object registry.

An implementation of this interface
should implement Object.equals(java.lang.Object) to return true when
passed an instance that represents the same (functionally equivalent)
server socket factory, and false otherwise (and it should also
implement Object.hashCode() consistently with its
Object.equals implementation).

An RMISocketFactory instance is used by the RMI runtime
in order to obtain client and server sockets for RMI calls.  An
application may use the setSocketFactory method to
request that the RMI runtime use its socket factory instance
instead of the default implementation.

The default socket factory implementation performs a
three-tiered approach to creating client sockets. First, a direct
socket connection to the remote VM is attempted.  If that fails
(due to a firewall), the runtime uses HTTP with the explicit port
number of the server.  If the firewall does not allow this type of
communication, then HTTP to a cgi-bin script on the server is used
to POST the RMI call. The HTTP tunneling mechanisms are disabled by
default. This behavior is controlled by the java.rmi.server.disableHttp
property, whose default value is true. Setting this property's
value to false will enable the HTTP tunneling mechanisms.

Deprecated: HTTP Tunneling. The HTTP tunneling mechanisms
described above, specifically HTTP with an explicit port and HTTP to a
cgi-bin script, are deprecated. These HTTP tunneling mechanisms are
subject to removal in a future release of the platform.

The default socket factory implementation creates server sockets that
are bound to the wildcard address, which accepts requests from all network
interfaces.

A ServerCloneException is thrown if a remote exception occurs
during the cloning of a UnicastRemoteObject.

As of release 1.4, this exception has been retrofitted to conform to
the general purpose exception-chaining mechanism.  The `nested exception`
that may be provided at construction time and accessed via the public
detail field is now known as the cause, and may be
accessed via the Throwable.getCause() method, as well as
the aforementioned `legacy field.`

Invoking the method Throwable.initCause(Throwable) on an
instance of ServerCloneException always throws IllegalStateException.

An ServerNotActiveException is an Exception
thrown during a call to RemoteServer.getClientHost if
the getClientHost method is called outside of servicing a remote
method call.

Deprecated.
No replacement. This interface is unused and is obsolete.

Deprecated.
no replacement.  Skeletons are no longer required for remote
 method calls in the Java 2 platform v1.2 and greater.

Deprecated.
no replacement.  Skeletons are no longer required for remote
 method calls in the Java 2 platform v1.2 and greater.

Deprecated.
no replacement.  Skeletons are no longer required for remote
 method calls in the Java 2 platform v1.2 and greater.

Deprecated.
This class is obsolete. Use ExportException instead.

A UID represents an identifier that is unique over time
with respect to the host it is generated on, or one of 216
`well-known` identifiers.

The UID() constructor can be used to generate an
identifier that is unique over time with respect to the host it is
generated on.  The UID(short) constructor can be used to
create one of 216 well-known identifiers.

A UID instance contains three primitive values:

unique, an int that uniquely identifies
the VM that this UID was generated in, with respect to its
host and at the time represented by the time value (an
example implementation of the unique value would be a
process identifier),
 or zero for a well-known UID
time, a long equal to a time (as returned
by System.currentTimeMillis()) at which the VM that this
UID was generated in was alive,
or zero for a well-known UID
count, a short to distinguish
UIDs generated in the same VM with the same
time value


An independently generated UID instance is unique
over time with respect to the host it is generated on as long as
the host requires more than one millisecond to reboot and its system
clock is never set backward.  A globally unique identifier can be
constructed by pairing a UID instance with a unique host
identifier, such as an IP address.

Used for exporting a remote object with JRMP and obtaining a stub
that communicates to the remote object. Stubs are either generated
at runtime using dynamic proxy objects, or they are generated statically
at build time, typically using the rmic tool.

Deprecated: Static Stubs. Support for statically
generated stubs is deprecated. This includes the API in this class that
requires the use of static stubs, as well as the runtime support for
loading static stubs.  Generating stubs dynamically is preferred, using one
of the five non-deprecated ways of exporting objects as listed below. Do
not run rmic to generate static stub classes. It is unnecessary, and
it is also deprecated.

There are six ways to export remote objects:



Subclassing UnicastRemoteObject and calling the
UnicastRemoteObject() constructor.

Subclassing UnicastRemoteObject and calling the
UnicastRemoteObject(port) constructor.

Subclassing UnicastRemoteObject and calling the
UnicastRemoteObject(port, csf, ssf) constructor.

Calling the
exportObject(Remote) method.
Deprecated.

Calling the
exportObject(Remote, port) method.

Calling the
exportObject(Remote, port, csf, ssf) method.



The fourth technique, exportObject(Remote),
always uses statically generated stubs and is deprecated.

The other five techniques all use the following approach: if the
java.rmi.server.ignoreStubClasses property is true
(case insensitive) or if a static stub cannot be found, stubs are generated
dynamically using Proxy objects. Otherwise,
static stubs are used.

The default value of the
java.rmi.server.ignoreStubClasses property is false.

Statically generated stubs are typically pregenerated from the
remote object's class using the rmic tool. A static stub is
loaded and an instance of that stub class is constructed as described
below.



A `root class` is determined as follows: if the remote object's
class directly implements an interface that extends Remote, then
the remote object's class is the root class; otherwise, the root class is
the most derived superclass of the remote object's class that directly
implements an interface that extends Remote.

The name of the stub class to load is determined by concatenating
the binary name of the root class with the suffix _Stub.

The stub class is loaded by name using the class loader of the root
class. The stub class must extend RemoteStub and must have a
public constructor that has one parameter of type RemoteRef.

Finally, an instance of the stub class is constructed with a
RemoteRef.

If the appropriate stub class could not be found, or if the stub class
could not be loaded, or if a problem occurs creating the stub instance, a
StubNotFoundException is thrown.



Stubs are dynamically generated by constructing an instance of
a Proxy with the following characteristics:



The proxy's class is defined by the class loader of the remote
object's class.

The proxy implements all the remote interfaces implemented by the
remote object's class.

The proxy's invocation handler is a RemoteObjectInvocationHandler instance constructed with a
RemoteRef.

If the proxy could not be created, a StubNotFoundException
will be thrown.

A remote object implementation should implement the
Unreferenced interface to receive notification when there are
no more clients that reference that remote object.