In the BootstrapExample exercise of the superb RMI tutorial from jGuru at the Java Developer Connection, the on-demand loading of classes by an RMI client refuses to run on the Java 2 SDK v1.2.2 platform. While the lightweight HTTP class server and the RMI server work fine, the bootstrap class loader on the client side produces the following error message

Avi Kak

The code supplied with the tutorial is contained in a number of different files, some containing classes and others containing command line statements. Use the following for the runclient.bat file on the client side:

//////   client file:  runclient.bat   //////

java -Djava.security.policy=/RMI5.d/policy 
    -Djava.rmi.server.codebase=http://rvl4.ecn.purdue.edu:2002/ RMIClientLoader

where you must replace the string rvl4.ecn.purdue.edu by the name of your computer that is providing the HTTP service for downloading the classes needed by your client program. You'd also need to replace the string RMI5.d by the pathname of the client-side directory containing the policy file. The policy file contains:

//////   client file:  policy   //////

grant codebase "file:/RMI5.d/" {
  permission java.net.SocketPermission "rvl4.ecn.purdue.edu", "connect";

where you'd need to replace the string RMI5.d by the pathname to the directory containing the RMI code on the client side. You'd also need to replace rvl4.ecn.purdue.edu as before.

An alternative solution consists of incorporating on the client side the following null override definition for the checkPermission() method in the RMIClientBootstrapSecurityManager class:


        public void checkPermission( Permission perm ) {}

Although this works, it is not a good option since it violates the spirit of the RMIClientBootstrapSecurityManager class. The idea behind the RMIClientBootstrapSecurityManager class is to have a minimally relaxed version of RMISecurityManager for the RMIClassLoader to bootstrap load the stubs and the other support classes and interfaces on the client side. A null override for checkPermission() throws the security control wide open.

Another equally unsafe option is to not use the RMIClientBootstrapSecurityManager class at all in RMIClassLoader. That is, to use just the RMISecurityManager with a wide-open security policy.

While you are modifying the code, you might as well comment out the following line on the server side:


      System.setSecurityManager( new RMIServerSecurityManager() );

from the main() of the RMIServer class. Setting a security manager on the server side serves no useful function in this example.