In the previous Classpath releases, an instance of a UnicastRemoteObject could be accessed from a server that:

- has created an instance of that object
- has been running all the time

The the activation system allows to activate and execute the object implementation on demand rather than running all time. If the activation system is persistent, the server can be terminated and then restarted. The clients, still holding remote references to the server side activatable objects, will activate those objects again. The server side objects will be reinstantiated (activated) during the first call of any remote method of such object.

The RMI client code for activatable objects is no different than the code for accessing non-activatable remote objects. Activation is a server-side feature.

In order for an object to be activated, the "activatable" object class (independently if it extends the {@link Activatable} class or not) defines a special public constructor that takes two arguments, its activation identifier ({@link ActivationID}) and its activation data ({@link java.rmi.MarshalledObject}), supplied in the activation descriptor used during registration. When an activation group activates a remote object, it constructs the object via this special constructor. The remote object implementation may use the activation data to initialize itself in a needed manner. The remote object may also retain its activation identifier, so that it can inform the activation group when it becomes inactive (via a call to the Activatable.inactive method).

@author Audrius Meskauskas (audriusa@bioinformatics.org) (from empty)