The RMI runtime system has a dynamic
class-loading 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
each machine participating in the application). For instance, when
discussing the earlier
Account example, we assumed
all the relevant classes (
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 ...