As mentioned, the SST and RMI distributed GC algorithms are radically different, thus incompatible. As a result, SST must take a conservative approach to collecting exported objects. That is, they are not collected. SST ensures that leases for imported objects are kept up to date and that references no longer needed are cleaned. The net effect of this is that your exporting objects must manage their unexporting explicitly; even if the object was implicitly exported.

This may seem a bit much to ask, since in a typical client-server environment only the service objects are exported and they become garbage only when the service is shut down. However, this approach is technically correct in that no non-garbage object will ever be incorrectly collected. Note that because SST adheres to RMI's notion of client behavior with respect to DGC, objects exported by a Java server will be correctly garbage collected.

Java is a typed language and Smalltalk is not. To interact with Java, Smalltalk must have access to certain type information. There is some information about this mapping which simply cannot be computed (for example, the mapping between Java classes and Smalltalk classes or Java method signatures and Smalltalk method selectors). You must provide this information. As such, it is not possible to implement a dynamic type discovery mechanism similar to that of CORBA. You must pre-build your Java type repository with the Java types encountered when running your programs.

When mapping objects between Java and Smalltalk, you are typically mapping instances. However, it is possible to map a Smalltalk class to an instance of a Java object. SST provides an example of this technique in the SstPingPongRmi example. Notice that the sstRmiClassName method appears on both the class and instance side of SstPingPongRmi example.