|back to j2megame.org|
|PREV NEXT||FRAMES NO FRAMES|
|java.rmi||Provides the RMI package.|
|java.rmi.activation||Provides support for RMI Object Activation.|
|java.rmi.dgc||Provides classes and interface for RMI distributed garbage-collection (DGC).|
|java.rmi.registry||Provides a class and two interfaces for the RMI registry.|
|java.rmi.server||Provides classes and interfaces for supporting the unicast server side of RMI.|
The Java(TM) 2 Platform, Micro Edition (J2ME(TM)), Remote Method
Invocation (RMI) Optional Package is a J2ME Connected Device
Configuration (CDC) Optional Package. The J2ME CDC requires a
complete implementation of the Java virtual machine (JVM)*
specification and core Java APIs including
java.util. Implementations of the RMI Optional Package
can only function on devices that include support for the J2ME CDC and
the Foundation Profile.
This document assumes that the reader is familiar with the Connected Limited Device Configuration (CLDC) specification available at
the CDC specification available at
the Foundation Profile specification available at
and the Java 2 Platform, Standard Edition (J2SE(TM)) 1.3 RMI specification available at
Note that J2ME Configurations and Profiles are defined in the Connected Limited Device Configuration Specification, Appendix 1, and J2ME Optional Packages are defined in the J2ME Platform Specification available at
This document specifies the subset of the J2SE 1.3 RMI API that is
included in the RMI Optional Package. Information on the J2SE 1.3 RMI
API is available at
This specification was developed under the Java Community Process(SM).
More information on the Java Community Process is available at
The API for the J2ME RMI Optional Package is a subset of the J2SE 1.3 RMI API that may be used with J2ME. Where not explicitly stated, this RMI Optional Package conforms to the J2SE 1.3 RMI specification. Classes from the J2SE 1.3 RMI API are completely supported, or modified in ways allowed by the J2ME Platform Specification. Implementations of the RMI Optional Package must support the following "client-oriented" interfaces and functionality specified by the J2SE 1.3 RMI API:
Full RMI call semantics
The RMI infrastructure supports passing serializable objects as the arguments and return values of remote method invocations. When the code for the class of an object within a remote method invocation's arguments or return value is not available to the JVM that is receiving the object, RMI will use dynamic class loading to obtain the class definition and make it available to the receiving JVM. Implementations of the RMI Optional Package must implement full RMI call semantics, including dynamic class loading.
This specification requires support of marshalled object
manipulation and persistence through the
The J2SE 1.3 RMI specification describes a wire protocol that enables remote method invocations to be communicated over a network. Except where noted below, implementations of this optional package must support this wire protocol, known as JRMP.
This specification requires implementations of the RMI Optional Package to support the "export" of unicast remote object implementations. When a remote object implementation is exported to the RMI runtime, remote method invocations from clients of that object will be dispatched to and executed by the implementation object.
An implementation of the RMI Optional Package must include these interfaces and support the RMI distributed garbage collection mechanism, which allows remote implementation objects to be garbage collected when all remote and local references to that object have been discarded.
As of J2SE 1.2, RMI remote object stubs can contain a remote reference to an "activatable" object. Activatable objects can be active or inactive. Remote references to activatable objects engage in an activation protocol that causes an inactive remote object to become active when a remote method is invoked on the object. The remote reference contained in a client stub object is responsible for engaging in the activation protocol. An implementation of the RMI Optional Package must support a remote object reference type that will engage in the activation protocol.
An implementation of the RMI Optional Package must support lookup
of remote objects through the standard registry interfaces
and the class
The following interfaces and functionality defined by the J2SE 1.3 RMI specification and API are not part of the specification for this RMI Optional Package and cannot be added to a conforming RMI Optional Package implementation:
The RMI protocol for remote call tunneling over HTTP. This protocol enables clients that are separated from remote objects by a firewall to "tunnel" remote method invocation through the firewall to the remote object implementation through one or more HTTP proxies.
The protocol described in section 10.6 of the J2SE 1.3 RMI specification for enabling multiple logical data streams to be multiplexed onto a single physical data stream. This protocol can enable two JVMs to invoke symmetric remote methods on each other even when only a single communication stream exists between the two JVMs.
The RMI mechanism for supporting activatable remote object implementations enables a remote object to become inactive when it is not in use and to become active when a client invokes a method on that implementation. Server side support for Activatable objects and the Remote Method Invocation Daemon (rmid) are not part of this specification.
The following J2SE 1.3 RMI APIs related to the implementation model for an "activatable" object are not part of the RMI Optional Package API:
See the discussion of system properties below for the missing RMI activation property.
The following J2SE 1.3 RMI APIs, which were deprecated as of J2SE 1.3, are not part of this specification:
java.rmi.server.RemoteRef.newCall(RemoteObject, Operation, int, long)
The following class in the J2SE 1.3 RMI API is also not part of this specification:
The J2SE 1.3 specification describes a tool that generates and compiles code for RMI stubs and skeletons (known as rmic). This RMI Optional Package specification does not require such a stub and skeleton compiler utility. Applications that need to generate RMI stub classes to be used with an implementation of the RMI Optional Package can use the stub compiler that is part of the J2SE 1.3 distribution.
In JDK 1.1, RMI supported a single "stub/skeleton" protocol for communication between a client-side stub and the server-side skeleton used to carry out the actual invocations on a remote object. In J2SE 1.2, RMI added support for an improved stub protocol that does not require any application-specific server-side skeleton classes. The older, JDK 1.1 stub/skeleton protocol is not part of this specification. The RMI Optional Package only supports application stub classes that use the 1.2 stub protocol. Stubs that are compatible with both the 1.1 and 1.2 stub protocols (such as those generated using the -vcompat command line option to the rmic stub compiler) are supported by the RMI Optional Package, but all RMI Optional Package communication must be carried out over the 1.2 stub protocol except for communication with a distributed garbage collector implementation and standard registry implementations.
Please see the following URLs for further information on rmic:
For the Solaris(TM) Operating Environment:
For the Microsoft Windows platform:
The RMI Optional Package requires implementations of the Foundation Profile and the J2ME CDC. The RMI Optional Package for J2ME/CDC is not supported by the J2ME Connected Limited Device Configuration (CLDC).
* As used on this webpage, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
|J2ME RMI Optional Package|
|PREV NEXT||FRAMES NO FRAMES|