This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Okay, I might not understand this completely but if one of the raging advantages to RMI is to be able to download classes dynamically, what good is that if you have to first get the Interface code over to the client to begin with? Server: Interface, Implementation Client: Client, (can't compile the client without the interface so we have to transfer it manually, not by dynamically downloading it. And so many people have problems getting dynamic downloading to work their advice is: Just copy the _Stub class over to the client. A common answer in the java.sun forum. That also seems to defeat the point of dynamic downloading.
First, let's make sure we're sharing the same terms. Properly speaking, the feature is called dynamic stub downloading. In other words, the client always has the interface the stub implements at compile time. So all we're really looking for is a serialized object (of type Stub) which will match up to the criteria of the interface (all the interface's methods implemented). This may seem like a limitation when compared to pure dynamic indentification of a service -- that is, finding both serivce (interface) and implementation (stubs) dynamically -- but I submit this is the thing I would find difficult to care about. What I do want is knowledge of a service type for which there may be any number of implementations available at run-time. For example, I "know" how all printers work ( public Job print(File f)... ); but I don't know who provides this service, much less where to find them. If I can identify a lookup service and ask "whatcha got that fits this type," that will return a list of implementations, I can apply my service type against these returned "stubs" to get my printing done. Now, as far as differentiating goes among services when I get more than one match, that's partly what Jini adds to this RMI-based model: a lookup service that is more robust than rmiregistry, and a way to convey stubs quickly to requesting clients. Jini also adds a way for services to "time out" of the lookup service if it doesn't check in on a regular basis. When I get some time this weekend, I'll continue the 'RMI from start to finish' topic to say more about this. It's a ways off, tying Jini into that discussion, but that's where we're headed.
Make visible what, without you, might perhaps never have been seen. - Robert Bresson