RMI's dynamic proxy stub implementation

Question

I want to understand how the dynamic proxy stub implementation is actually done behind the scene. According to what I read, by the time a remote object is exported if no pre-generated stub class is found, the RMI runtime would generate a dynamic proxy to act as the stub. That stub is then bound to the RMI Registry and later accessible by some RMI client.

The question is: since the stub is actually a dynamically generated proxy, its class definition would not be available on the client side, then how come the client is still able to retrieve the stub from the RMI Registry? Is there some kind of dynamic class-loading happening behind the scene or does RMI use another technique to work-around this?

Answer 1

Java.lang.reflect.Proxy is serializable and it has special support in ObjectOutputStream and ObjectInputStream. Basically just the interfaces implemented and the invocation handler are serialized, and a new dynamic proxy is constructed from that during deserialization.

Answer 2

RMI does use dynamic classloading - the classpath is sent alongwith the call as a 'classpath annotation' from which the client loads the class. You can look at the RMI implementation for more info - it's available as part of the JDK source. Specifically, the classes ObjectOutputStream and RMIClassloader.

Update: RMI does not start an HTTP server - in fact, you would need your custom solution for this. One of them as you mention can be an HTTP server that you run, make the classes available through the server, and pass the codebase with the HTTP server's address/port in your stubs, so that your clients can download them.