Sponsored Link •
The semantics of annotated codebases is useful even outside the RMI runtime environment -- in other words, for objects that are not transferred from one JVM to another in the context of an RMI call. In a dynamic environment, when objects are transferred from one JVM to another, you will likely need to transfer the required classes for these objects as well. Since they do not benefit from codebase annotations of the RMI runtime, they need to offer codebase information to client JVMs in a different way.
java.rmi.MarshalledObject class is used for that purpose (see the Java Remote Method Invocation Specification, Section 7.4.9). Creating a
MarshalledObject instance involves passing a serializable object to its constructor.
MarshalledObject uses the special output stream of the RMI system that obtains the codebase property specified for the running VM, and saves this information along with the original object's serialized form.
get() method returns the original object by downloading the needed classfile and reconstructing the object's state. Comparing two
MarshalledObject instances produces equality if the two refer to the same object, regardless of the codebases specified.
When a service registers with a lookup service, it provides a
ServiceItem to the lookup service's registrar. The service item contains the service ID, the service object, and a set of attributes associated with the service.
ServiceItem can hold an array of
Entry objects. Each
Entry specifies a set of attributes. Each attribute must be declared with reference types (no primitives allowed), and must be serializable objects. When an
Entry is serialized, each field it declares is serialized separately as a
MarshalledObject (see the Jini Core Platform Specification, Section EN.1.3). This also facilitates code mobility: when a client retrieves the service item with a lookup operation, it can reconstruct each