Java Remote Method Invocation (RMI) - JavaTech: An Introduction to Scientific and Technical Computing with Java - page 524

18.6.3 Create a client JAR file
When we run the server, we'll set the local CLASSPATH to point to the
build/classes directory tree. We could run the client pointing to the same
CLASSPATH ,but, as described earlier, doing so would not demonstrate the ability
of RMI to download bytecodes from a codebase. Instead, we create a JAR file
that contains only the pieces needed for the client to start up. It intentionally does
not include the stubs just generated by rmic . The only pieces absolutely required
for the client are the compiled RMIExampleClient.class file and the com-
piled interface file. The JAR file must be created carefully so that it contains the
directory structure matching the package structure of the compiled class files.
Therefore the JAR must begin at the build/classes directory level. One way
to do that is to use the -C switch to the jar command. It is often easier to just
cd to the required root directory, run the jar command, and then cd back to the
starting location, the approach used here:
cd build \ classes
jar cf client.jar
javatech/rmi18/server/RMIExampleInterface.class
javatech/rmi18/client/RMIExampleClient.class
move client.jar .. \ ..
cd .. \ ..
(The list of files to include in the JAR file is too long to fit on one line. On Unix
and Linux platforms, a continuation character ( “\ „ ) can be used to nicely format
the script file, but on Windows both files must appear in one long line. We've
split it here only for appearance reasons.)
Note that we've also moved the created client.jar back up two directories,
back to the javatech-18 root directory for this example.
18.6.4 Start the RMI registry
The next step is to start the RMI registry. When doing so, it is important that the
registry be started without a CLASSPATH that includes the stub files. In general,
no CLASSPATH at all should be used. In all the examples shown so far, we've
assumed that the command shell window does not have a CLASSPATH envi-
ronment variable set. We explicitly set the CLASSPATH using the -classpath
command line switch whenever necessary. The reason that no CLASSPATH should
be set is that the registry is a Java application, and like any Java application, the
JVM looks first in its local CLASSPATH for the class files it needs. The files
the registry needs are the stub classes. If the registry finds the stub classes in its
CLASSPATH , then it won't look in the java.rmi.server.codebase . When
a client asks the registry for the codebase, there won't be one, and the client will
fail with a nested ClassNotFoundException . Therefore, we intentionally