The RMI runtime system has a dynamic classloading
facility that loads the classes it needs while executing remote method
calls. In some situations, you don’t need to worry much about how your
application classes are obtained by the various agents in an RMI
application. This is especially true if you have direct access to all
hosts involved in the distributed system (i.e., if you can install
your application classes in the local
CLASSPATH for each machine participating in
the application). For instance, when discussing the earlier
Account example, we assumed all the relevant
AccountImpl, stub, and skeleton classes)
were installed on both the client and the server. However, if your
distributed application involves remote agents running on hosts that
aren’t directly under your control, you need to understand how RMI
loads classes at runtime, so you can ensure that each remote agent can
find the classes it needs in order to run.
As with any Java application, the Java runtime system is responsible for loading the classes needed to initiate an RMI session. Starting an interaction with a remote object means loading the RMI API classes themselves, as well as the base interface for the remote object and the stub class for the remote interface. On the server side, the skeleton class for the remote object and the actual implementation class need to be loaded in order to run the server object that is being remotely exported.
The classes that are referenced ...