An AccessException is thrown by certain methods of the
java.rmi.Naming class (specifically bind,
rebind, and unbind) and methods of the
java.rmi.activation.ActivationSystem interface to
indicate that the caller does not have permission to perform the action
requested by the method call.  If the method was invoked from a non-local
host, then an AccessException is thrown.

The Activatable class provides support for remote
objects that require persistent access over time and that
can be activated by the system.

For the constructors and static exportObject methods,
the stub for a remote object being exported is obtained as described in
UnicastRemoteObject.

An attempt to serialize explicitly an instance of this class will
fail.

This exception is thrown by the RMI runtime when activation
fails during a remote call to an activatable object.

An activation descriptor contains the information necessary to
activate an object:
 the object's group identifier,
 the object's fully-qualified class name,
 the object's code location (the location of the class), a codebase URL
path,
 the object's restart "mode", and,
 a "marshalled" object that can contain object specific
initialization data.

A descriptor registered with the activation system can be used to
recreate/activate the object specified by the descriptor. The
MarshalledObject in the object's descriptor is passed
as the second argument to the remote object's constructor for
object to use during reinitialization/activation.

General exception used by the activation interfaces.

As of release 1.4, this exception has been retrofitted to conform to
the general purpose exception-chaining mechanism.  The "detail 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 ActivationException always throws IllegalStateException.

An ActivationGroup is responsible for creating new
instances of "activatable" objects in its group, informing its
ActivationMonitor when either: its object's become
active or inactive, or the group as a whole becomes inactive.

An ActivationGroup is initially created in one
of several ways:
as a side-effect of creating an ActivationDesc
    without an explicit ActivationGroupID for the
    first activatable object in the group, or
via the ActivationGroup.createGroup method
as a side-effect of activating the first object in a group
    whose ActivationGroupDesc was only registered.

Only the activator can recreate an
ActivationGroup.  The activator spawns, as needed, a
separate VM (as a child process, for example) for each registered
activation group and directs activation requests to the appropriate
group. It is implementation specific how VMs are spawned. An
activation group is created via the
ActivationGroup.createGroup static method. The
createGroup method has two requirements on the group
to be created: 1) the group must be a concrete subclass of
ActivationGroup, and 2) the group must have a
constructor that takes two arguments:


 the group's ActivationGroupID, and
 the group's initialization data (in a
     java.rmi.MarshalledObject)

When created, the default implementation of
ActivationGroup will override the system properties
with the properties requested when its
ActivationGroupDesc was created, and will set a
SecurityManager as the default system
security manager.  If your application requires specific properties
to be set when objects are activated in the group, the application
should create a special Properties object containing
these properties, then create an ActivationGroupDesc
with the Properties object, and use
ActivationGroup.createGroup before creating any
ActivationDescs (before the default
ActivationGroupDesc is created).  If your application
requires the use of a security manager other than
SecurityManager, in the
ActivativationGroupDescriptor properties list you can set
java.security.manager property to the name of the security
manager you would like to install.

ActivationGroup_Stub is a stub class
for the subclasses of java.rmi.activation.ActivationGroup
that are exported as a java.rmi.server.UnicastRemoteObject.

An activation group descriptor contains the information necessary to
create/recreate an activation group in which to activate objects.
Such a descriptor contains:
 the group's class name,
 the group's code location (the location of the group's class), and
 a "marshalled" object that can contain group specific
initialization data.

The group's class must be a concrete subclass of
ActivationGroup. A subclass of
ActivationGroup is created/recreated via the
ActivationGroup.createGroup static method that invokes
a special constructor that takes two arguments:

 the group's ActivationGroupID, and
 the group's initialization data (in a
java.rmi.MarshalledObject)

Startup options for ActivationGroup implementations.

This class allows overriding default system properties and
specifying implementation-defined options for ActivationGroups.

The identifier for a registered activation group serves several
purposes:
identifies the group uniquely within the activation system, and
contains a reference to the group's activation system so that the
group can contact its activation system when necessary.

The ActivationGroupID is returned from the call to
ActivationSystem.registerGroup and is used to identify
the group within the activation system. This group id is passed
as one of the arguments to the activation group's special constructor
when an activation group is created/recreated.

Activation makes use of special identifiers to denote remote
objects that can be activated over time. An activation identifier
(an instance of the class ActivationID) contains several
pieces of information needed for activating an object:

 a remote reference to the object's activator (a RemoteRef
instance), and
 a unique identifier (a UID
instance) for the object.

An activation identifier for an object can be obtained by registering
an object with the activation system. Registration is accomplished
in a few ways:
via the Activatable.register method
via the first Activatable constructor (that takes
three arguments and both registers and exports the object, and
via the first Activatable.exportObject method
that takes the activation descriptor, object and port as arguments;
this method both registers and exports the object.

An ActivationInstantiator is responsible for creating
instances of "activatable" objects. A concrete subclass of
ActivationGroup implements the newInstance
method to handle creating objects within the group.

An ActivationMonitor is specific to an
ActivationGroup and is obtained when a group is
reported active via a call to
ActivationSystem.activeGroup (this is done
internally). An activation group is responsible for informing its
ActivationMonitor when either: its objects become active or
inactive, or the group as a whole becomes inactive.

The ActivationSystem provides a means for registering
groups and "activatable" objects to be activated within those groups.
The ActivationSystem works closely with the
Activator, which activates objects registered via the
ActivationSystem, and the ActivationMonitor,
which obtains information about active and inactive objects,
and inactive groups.

The Activator facilitates remote object activation. A
"faulting" remote reference calls the activator's
activate method to obtain a "live" reference to a
"activatable" remote object. Upon receiving a request for activation,
the activator looks up the activation descriptor for the activation
identifier, id, determines the group in which the
object should be activated initiates object re-creation via the
group's ActivationInstantiator (via a call to the
newInstance method). The activator initiates the
execution of activation groups as necessary. For example, if an
activation group for a specific group identifier is not already
executing, the activator initiates the execution of a VM for the
group.

The Activator works closely with
ActivationSystem, which provides a means for registering
groups and objects within those groups, and ActivationMonitor,
which recives information about active and inactive objects and inactive
groups.

The activator is responsible for monitoring and detecting when
activation groups fail so that it can remove stale remote references
to groups and active object's within those groups.

An UnknownGroupException is thrown by methods of classes and
interfaces in the java.rmi.activation package when the
ActivationGroupID parameter to the method is determined to be
invalid, i.e., not known by the ActivationSystem.  An
UnknownGroupException is also thrown if the
ActivationGroupID in an ActivationDesc refers to
a group that is not registered with the ActivationSystem

An UnknownObjectException is thrown by methods of classes and
interfaces in the java.rmi.activation package when the
ActivationID parameter to the method is determined to be
invalid.  An ActivationID is invalid if it is not currently
known by the ActivationSystem.  An ActivationID
is obtained by the ActivationSystem.registerObject method.
An ActivationID is also obtained during the
Activatable.register call.

An AlreadyBoundException is thrown if an attempt
is made to bind an object in the registry to a name that already
has an associated binding.

A ConnectException is thrown if a connection is refused
to the remote host for a remote method call.

A ConnectIOException is thrown if an
IOException occurs while making a connection
to the remote host for a remote method call.

The DGC abstraction is used for the server side of the distributed
garbage collection algorithm. This interface contains the two
methods: dirty and clean. A dirty call is made when a remote
reference is unmarshaled in a client (the client is indicated by
its VMID). A corresponding clean call is made when no more
references to the remote reference exist in the client. A failed
dirty call must schedule a strong clean call so that the call's
sequence number can be retained in order to detect future calls
received out of order by the distributed garbage collector.

A reference to a remote object is leased for a period of time by
the client holding the reference. The lease period starts when the
dirty call is received. It is the client's responsibility to renew
the leases, by making additional dirty calls, on the remote
references it holds before such leases expire. If the client does
not renew the lease before it expires, the distributed garbage
collector assumes that the remote object is no longer referenced by
that client.

A lease contains a unique VM identifier and a lease duration. A
Lease object is used to request and grant leases to remote object
references.

A VMID is a identifier that is unique across all Java virtual
machines.  VMIDs are used by the distributed garbage collector
to identify client VMs.

A MarshalException is thrown if a
java.io.IOException occurs while marshalling the remote call
header, arguments or return value for a remote method call.  A
MarshalException is also thrown if the receiver does not
support the protocol version of the sender.

If a MarshalException occurs during a remote method call,
the call may or may not have reached the server.  If the call did reach the
server, parameters may have been deserialized.  A call may not be
retransmitted after a MarshalException and reliably preserve
"at most once" call semantics.

A MarshalledObject contains a byte stream with the serialized
representation of an object given to its constructor.  The get
method returns a new copy of the original object, as deserialized from
the contained byte stream.  The contained object is serialized and
deserialized with the same serialization semantics used for marshaling
and unmarshaling parameters and return values of RMI calls:  When the
serialized form is created:


 classes are annotated with a codebase URL from where the class
     can be loaded (if available), and
 any remote object in the MarshalledObject is
     represented by a serialized instance of its stub.


When copy of the object is retrieved (via the get method),
if the class is not available locally, it will be loaded from the
appropriate location (specified the URL annotated with the class descriptor
when the class was serialized.

MarshalledObject facilitates passing objects in RMI calls
that are not automatically deserialized immediately by the remote peer.

The Naming class provides methods for storing and obtaining
references to remote objects in a remote object registry.  Each method of
the Naming class takes as one of its arguments a name that
is a java.lang.String in URL format (without the
scheme component) of the form:



   //host:port/name

where host is the host (remote or local) where the registry
is located, port is the port number on which the registry
accepts calls, and where name is a simple string uninterpreted
by the registry. Both host and port are optional.
If host is omitted, the host defaults to the local host. If
port is omitted, then the port defaults to 1099, the
"well-known" port that RMI's registry, rmiregistry, uses.

Binding a name for a remote object is associating or
registering a name for a remote object that can be used at a later time to
look up that remote object.  A remote object can be associated with a name
using the Naming class's bind or
rebind methods.

Once a remote object is registered (bound) with the RMI registry on the
local host, callers on a remote (or local) host can lookup the remote
object by name, obtain its reference, and then invoke remote methods on the
object.  A registry may be shared by all servers running on a host or an
individual server process may create and use its own registry if desired
(see java.rmi.registry.LocateRegistry.createRegistry method
for details).

A NoSuchObjectException is thrown if an attempt is made to
invoke a method on an object that no longer exists in the remote virtual
machine.  If a NoSuchObjectException occurs attempting to
invoke a method on a remote object, the call may be retransmitted and still
preserve RMI's "at most once" call semantics.

A NoSuchObjectException is also thrown by the method
java.rmi.server.RemoteObject.toStub and by the
unexportObject methods of
java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable and

A NotBoundException is thrown if an attempt
is made to lookup or unbind in the registry a name that has
no associated binding.

LocateRegistry is used to obtain a reference to a bootstrap
remote object registry on a particular host (including the local host), or
to create a remote object registry that accepts calls on a specific port.

 Note that a getRegistry call does not actually make a
connection to the remote host.  It simply creates a local reference to
the remote registry and will succeed even if no registry is running on
the remote host.  Therefore, a subsequent method invocation to a remote
registry returned as a result of this method may fail.

Registry is a remote interface to a simple remote
object registry that provides methods for storing and retrieving
remote object references bound with arbitrary string names.  The
bind, unbind, and rebind
methods are used to alter the name bindings in the registry, and
the lookup and list methods are used to
query the current name bindings.

In its typical usage, a Registry enables RMI client
bootstrapping: it provides a simple means for a client to obtain an
initial reference to a remote object.  Therefore, a registry's
remote object implementation is typically exported with a
well-known address, such as with a well-known ObjID and TCP port number
(default is 1099).

The LocateRegistry class provides a programmatic API for
constructing a bootstrap reference to a Registry at a
remote address (see the static getRegistry methods)
and for creating and exporting a Registry in the
current VM on a particular local address (see the static
createRegistry methods).

A Registry implementation may choose to restrict
access to some or all of its methods (for example, methods that
mutate the registry's bindings may be restricted to calls
originating from the local host).  If a Registry
method chooses to deny access for a given invocation, its
implementation may throw AccessException, which
(because it extends RemoteException) will be
wrapped in a ServerException when caught by a
remote client.

The names used for bindings in a Registry are pure
strings, not parsed.  A service which stores its remote reference
in a Registry may wish to use a package name as a
prefix in the name binding to reduce the likelihood of name
collisions in the registry.

Deprecated.
no replacement

The Remote interface serves to identify interfaces whose
methods may be invoked from a non-local virtual machine.  Any object that
is a remote object must directly or indirectly implement this interface.
Only those methods specified in a "remote interface", an interface that
extends java.rmi.Remote are available remotely.

Implementation classes can implement any number of remote interfaces and
can extend other remote implementation classes.  RMI provides some
convenience classes that remote object implementations can extend which
facilitate remote object creation.  These classes are
java.rmi.server.UnicastRemoteObject and
java.rmi.activation.Activatable.

For complete details on RMI, see the RMI Specification which describes the RMI API and system.

A RemoteException is the common superclass for a number of
communication-related exceptions that may occur during the execution of a
remote method call.  Each method of a remote interface, an interface that
extends java.rmi.Remote, must list
RemoteException in its throws clause.

As of release 1.4, this exception has been retrofitted to conform to
the general purpose exception-chaining mechanism.  The "wrapped remote
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 RemoteException always throws IllegalStateException.

Deprecated.
Use SecurityException instead.
 Application code should never directly reference this class, and
 RMISecurityManager no longer throws this subclass of
 java.lang.SecurityException.

Deprecated.
Use SecurityManager instead.

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.

A ServerError is thrown as a result of a remote method
invocation when an Error is thrown while processing
the invocation on the server, either while unmarshalling the arguments,
executing the remote method itself, or marshalling the return value.

A ServerError instance contains the original
Error that occurred as its cause.

A ServerException is thrown as a result of a remote method
invocation when a RemoteException is thrown while processing
the invocation on the server, either while unmarshalling the arguments or
executing the remote method itself.

A ServerException instance contains the original
RemoteException that occurred as its cause.

Deprecated.
no replacement

A StubNotFoundException is thrown if a valid stub class
could not be found for a remote object when it is exported.
A StubNotFoundException may also be
thrown when an activatable object is registered via the
java.rmi.activation.Activatable.register method.

An UnexpectedException is thrown if the client of a
remote method call receives, as a result of the call, a checked
exception that is not among the checked exception types declared in the
throws clause of the method in the remote interface.

An UnknownHostException is thrown if a
java.net.UnknownHostException occurs while creating
a connection to the remote host for a remote method call.

An UnmarshalException can be thrown while unmarshalling the
parameters or results of a remote method call if any of the following
conditions occur:

 if an exception occurs while unmarshalling the call header
 if the protocol for the return value is invalid
 if a java.io.IOException occurs unmarshalling
parameters (on the server side) or the return value (on the client side).
 if a java.lang.ClassNotFoundException occurs during
unmarshalling parameters or return values
 if no skeleton can be loaded on the server-side; note that skeletons
are required in the 1.1 stub protocol, but not in the 1.2 stub protocol.
 if the method hash is invalid (i.e., missing method).
 if there is a failure to create a remote reference object for
a remote object's stub when it is unmarshalled.