This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
This is confusing to me. If I have a class like so
Then I have execute code like so
I copied this from the example sort of. As you can see the object returned by the UnicastRemoteObject call is being labelled a 'stub'. But this makes no sense as you do not need a 'codebase' property set to get this. And it is not a 'class' per se, but it is only an instance of something essentially hidden from the user. Whatever UnicastRemoteObject returns.
In any case, in the example above, nothing needs to be downloaded, and certainly not the so-labelled 'stub'. AFAICT, instances do not require anything special to be transported across RMI, but only class definitions do. And stubs are instances and not class definitions.
So could someone help me with this confusing terminology and why one would ever require the codebase property to be set for a 'stub'. And the stub can not be 'ISomeInterface' because the client will require that when the JVM starts up right?
AFAICT is not the so-called 'stub' that needs to be downloaded. Its any classes that the 'stub' instance may contain that do not appear in the remote interface of the associated stub interface. So for example;
And the client will do something like so
In the above case the class AnotherClass will be required by the client since it is not a remote object but is instead passed as a parameter. It will be serialized and therefore its class definition will be needed when the client tries to deserialize it. Thus, codebase property and dynamic class downloading is never required unless you are passing non-remote objects as parameters. Thus, codebase is support for serialization and has nothing to do with stubs per se.
The sun documentation is completely misleading in this respect.
"The java.rmi.server.codebase property value represents one or more URL locations from which these stubs (and any classes needed by the stubs) can be downloaded."
This is simply false since stubs do not use codebase property to be 'downloaded.'
I think this is confusing because RMI was changed in JDK 1.5 - prior to 1.5 stubs had to be generated manually (and thus would have to be provided to the client statically as classes, or downloadable via codebase), post 1.5 stubs are generated automatically by the RMI subsystem. The documentation you're referring to may not have been updated to reflect this.
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
I am reading 1.5 documentation. I think it was updated but perhaps not in a clear enough way.
So you are suggesting that RMI now automatically can create stubs for the client and the client has no need to download stubs at all. This would match my experience. So when making calls on remote objects, the stubs are indeed required, but in 1.5 they are created automatically by the client itself. So no codebase property is required on 1.5 if you are not doing any serialization.
This makes more sense. So that object that is labeled as a stub, is indeed a stub. And the client will also get its own stub.
I am understanding more now. My codebase now only includes hibernate3.jar since the other classes are required to compile and start both the client and server anyway. Only classes not directly passed in the RMI interfaces but that does get serialized are the hibernate collections. So thats all I need in the codebase.