A popular use case of SST's RMI support is to write a server in Smalltalk and clients in Java. This differs from typical Java-only uses of RMI in that there need not be an actual Java class, only a stub. That is, there is no point in having a my.package.Foo Java class corresponding to the Smalltalk Foo class since it will never be instantiated.

Unfortunately, the standard way of constructing stubs (for example, my.package.Foo_Stub) is to create the class and then use the RMIC tool to generate the stub and skeleton. (Note that the skeleton is also not needed in the Java client case.)

As to SST, you have two options for building the required stubs. The first is to build a dummy my.package.Foo (and attendant interfaces) and use RMIC as normal. The class must have implementations for the methods in its interfaces. These implementations will never be run, since the class will never be instantiated, and so can be empty. This approach is straightforward but leads to a number of extraneous classes (for example, my.package.Foo and my.package.Foo_Skel). The second option is to use the type builder as described above to generate Java stubs in Smalltalk. The builder takes a Java class definition as mentioned above and generates the required interface and stub classes. The advantage of this approach that only those Java classes actually required (the stubs) are generated and the generation can be done from within Smalltalk. However, the disadvantage is that you must manipulate the SST Java type descriptions more directly. Both approaches have the same result: a Java stub class for my.package.Foo is created allowing Smalltalk objects to be referenced remotely from Java clients.