As far as I can see, given a IFoo interface extending Remote and a FooImpl class implementing IFoo, the following two code fragments are (almost) equivalent : (1)
IFoo stub = ( IFoo )UnicastRemoteObject.exportObject( new FooImpl() );
Naming.bind( "foo", stub );
and, if FooImpl is a class that extends UnicastRemoteObject : (2)
Naming.bind( "foo", new FooImpl() );
In fact, the FooImpl instance exportation is done in the implicit UnicastRemoteObject constructor call.
But in (1), the object returned by UnicastRemoteObject.exportObject() is a Proxy (dynamic) class, and consequently the object recorded in the RMI registry is obviously a reference. Whereas in (2), it is not clear.
Where is the Proxy construction based an a FooImpl instance realized ? I have seen that the RMI registry management in the client code (Naming.bind()) encapsulates a (registry) Proxy class creation with a call to LocateRegistry.getRegister(). So in the request :
Naming.bind( "foo", new FooImpl() )
is it the registry Proxy class invocation handler that handles the parameters extending Remote to transform them as references / Proxy classes ?
And in that case, given that the stub Proxy class in (1) is itself a Remote class, would that mean that the object stored in the registry is a reference to a reference (i.e. a Proxy calling another Proxy calling the real class) ?
Thanks.
When the FooImpl object is marshalled to the Registry in the bind() call it is automatically replaced by its stub. That happens for any exported remote object when used as a parameter or result of a remote method.