This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Note: Since posting this item, I have found out some of the answers, which I will offer in italics; of couse, it's always possible that my current understanding of what the correct answers are is incorrect. Hi, Summary of my question: The first four segments are a simple RMI client and server in package rmi2. They use the most standard technique for people first experimenting, where, namely, the ...Impl class extends UnicastRemoteObject thus:
However, what happens when your ...Impl class does not extend UnicastRemoteObject? Then you are free to extend some other class of your chosing. This whole idea would have worked out alright if and only if I didn't later place a restiction on my CommonInterface that it throw MyException; that is, the local object and the remote object that the client receives would have ended up as children both extending the same parent abstract class, and that abstract class would contain the methods that do most of the work. This plan works if CommonInterface has methods which throw Exception, but won't work if the methods throw either MyException for the local subclass and RemoteException for the remote object methods. The first step is to show the code, based on Core Java, but extended by me which is the four classes in package rmi2 which does things the simplest way people usually start out (i.e., the ...Impl class extends UnicastRemoteObject). Then I will come to my question.
So, I now define a new package called rmi3. I want to re-define GenImpl so that it does not extend UnicastRemoteObject. The reasoning is that it may buy me more flexibility (the analogy is to a class you want to make runnable, you can extend Thread, or for more flexibility, implement Runnable instead). Dutifully referring to my textbook on page 340 on the sidebar, it says, in effect, that to do what I want to do, I need to manually instantiate the server objects and pass them to the static exportObject method (noting that the server class must still implement a [programmer defined] remote interface). And, two examples, though not much context is given:
His use of the "Server Object" is refering to my GenImpl class. Anyway, although everything works fine, I never have to invoke UnicastRemoteObject.exportObject(...). Everything continues to work fine (both to the localhost or over a live internet connection). Question: why? Because all the classes were accessable, either in the rmi directory or in the .jar file; thus, no stubs needed to be transported across the network. [Note: the fact that no stubs are being transported across the network is why a security manager is not required.] If stubs needed to be transported across the network, then these exportObject(...) method calls would be imperative.
Here are the classes which significantly change in package rmi3, and they work even though UnicastRemoteObject.exportObject(...) is never invoked anywhere. Here is the most important change, as the following class extends Object (and in the real world, it would extend some class of mine instead, but Object should suffice for this test):
The class GenServer is unchanged, as the changes I tried to make: gen1.exportToRmi(port) for example, are not necessary, because everything works fine either 1. with the calls in 2. with the calls commented out.
Summary: how is this mystery about UnicastRemoteObject.exportObject(...) explained? I've retrospectively filled in some of the answers above. Thanks, Javini Javono [ January 25, 2004: Message edited by: Javini Javono ]