To better understand this section, examine the sample SstPingPongRmi.

RMI uses Java Object Serialization to convert objects to bytes and vice versa. As noted elsewhere in this document, SST uses Swapper or an SST-specific marshaler. These formats are completely incompatible.

RMI communications is largely TCP-based. While this presents no particular problem, the use of the TCP connections is specific to RMI. For example, RMI maintains a pool of connections between any two machines. If there are no available (existing or free) connections, a new connection is created. Connections used for a request are marked as in-use for the duration of that send (until the reply and related DGC messages have been exchanged). Standard SST on the other hand uses a more loosely coupled model which requires just one connection between any two hosts.

Both Smalltalk and Java are class-based object-oriented languages. Java however contains notions such as interfaces and types. While Smalltalk objects are uniformly self-describing, Java language elements sometimes need the help of a type or interface specification to determine how they should be handled (for example, primitive types). For Smalltalk to interact with Java, this information must be made available in the Smalltalk environment.

Given that Java is typed, transparent, generic remote references (in SST) are impossible. Instead, Java uses stubs and skeletons. A stub is a proxy similar to that of SST but is specific to a particular class. It defines all of the remote methods defined by the class' remote interfaces. These methods in effect trap message sends, marshal the arguments and send a message to the remote object for which the stub is a proxy. The effect is the same, the implementation is different. Skeletons are the server-side version of stubs. In JDK versions prior to 1.2, the skeleton code was class-specific and contained the necessary code to receive requests, unmarshal the arguments and dispatch the message to the proxied object. In later versions of the JDK, class-specific skeletons have been replaced with a generic option and are no longer necessary. The RMI Wizard generates the proper runtime structures based upon the level of JDK you indicate.

There are many possible DGC algorithms each with their own merits and short-comings. Java uses a DGC based on the Network Objects work by Birrel, et al, at Digital. SST uses a distributed mark/sweep algorithm loosely based on work at University of Tokyo by Kamada, et al. These two algorithms are fundamentally incompatible.