Why does an application that exports an RMI remote object need to be able to load the stub class?
A stub class is generated by rmic from the class file that defines a class for a remote object. The stub class implements all the same remote interfaces as the remote object’s class. When a client holds a remote reference to a remote object, it is actually holding a local reference to a local instance of the stub class for that remote object. Because the stub class implements all the same remote interfaces as the remote object’s class, the client can invoke any method on the stub through the remote interfaces that it could invoke on the remote object. Since the client must instantiate a stub object, it makes sense that the client needs to be able to load the class file for the stub class. The reason the server must also be able to load the stub class is less obvious. A stub class can be distributed along with clients, which enables the client to load the stub class from a local repository, such as from its local class path. However, RMI offers an alternative that makes it unnecessary t
Related Questions
- Why does my application sometimes receive a NativeSeqFile error when using JRIO and the Remote Method Invocation (RMI) - Java Remote Method Protocol (JRMP) to access MVS datasets?
- I am getting a ClassNotFoundException for my stub class when I try to register a remote object in the registry. Whats happening?
- Why does an application that exports an RMI remote object need to be able to load the stub class?
