create a .jar file that contains all (and only) the classes that you want to make accessible to
clients as part of the configuration of an RMI server. A common convention with such .jar
files is to give them a name that ends in dl (for download).
There are times that this mechanism can cause considerable confusion and complexity, espe-
cially for systems in which lots of different machines are passing lots of objects to each oth-
er. [ 36 ] But for most simple client/server applications, and even most complex ones, the ability
to pass by either reference or value, and the ability to download code to ensure that pass-by-
value passes just what you expect makes Java RMI a unique form of RPC. You need to be
careful (the ability to download code is the main reason that Java RMI should be run only
when there is a security manager present), but the end result can change the way you build
Like object serialization, there is much more to RMI than we have the space to discuss here.
The system has a form of distributed garbage collection and a mechanism that will activate
servers on demand. There are different ways of exporting objects and different ways of start-
ing up places to register a remote object so that clients of that object can find it. But the thing
that really makes RMI different is its ability to move code and data in a network of cooperat-
ing Java programs. That makes the system unique, and makes the system a good part of Java.
[ 28 ] Remote Method Invocation has an interesting history. The original plan for distributed computing in
Java made a Linda-like communication system the central mechanism for communication between vir-
tual machines. Ann Wollrath, then working for Sun Labs, argued that an RPC system would be needed
to implement such a system, and so was given the OK to work on an RPC layer that was not origin-
ally intended to become public. The resulting system was such a good fit into the Java programming
environment that it became public in Java 1.1. The Linda-like communication system was produced as
JavaSpaces, but never received the adoption of RMI.
[ 29 ] In the spirit of full disclosure, I should admit that I am not a disinterested observer of RMI. The ori-
ginal work for RMI was done in a group that I led (although I was working on other things at the time),
and I've been associated with the team and the technology from early on in its life. So in some ways,
writing about RMI is like writing about my children, with the main difference being that more people
are interested in RMI.
[ 30 ] Actually, the situation is somewhat more complex than this, since low-level virtual machines such as
Xen or VMWare mimic multiple physical machines on a single server. But referring to these as virtual
machines confuses these with the Java Virtual Machine. An RMI registry would only allow registration
on the same Xen instance. But we have only two words (physical and virtual) for at least three different
things (the actual hardware, the emulation in a Xen-style machine, and a Java virtual machine), so there
are times when it gets confusing.