Java Network Programming, Second Edition

Loading Classes at Runtime

All the client really has to know about the remote object is its remote interface. Everything else it needs—for instance, the stub classes—can be loaded from a web server (though not an RMI server) at runtime using a class loader. Indeed, this ability to load classes from the network is one of the unique features of Java. This is especially useful in applets. The web server can send the browser an applet that communicates back with the server for instance, to allow the client to read and write files on the server. As with any time that classes are loaded from a potentially untrusted host, they must be checked by a SecurityManager.

Unfortunately, while remote objects are actually quite easy to work with when you can install the necessary stubs and classes in the local client class path, doing so when you have to dynamically load the stubs and other classes is fiendishly difficult. While Sun is good at application programming interface design, it is poor at user interface design. The class path, the security architecture, and the reliance on poorly documented environment variables are all bugbears that torment Java programmers. Getting a local client object to download remote objects from a server requires manipulating all of these in precise detail. Making even a small mistake will prevent programs from running, with only the most generic of exceptions being provided to tell the poor programmer what he or she did wrong. Exactly how difficult it is to ...