Copyright (c) SEMM NL All rights reserved.
Author : Paul Hamaker. Part of




In we describe the methods that our server has to offer :

And so it does, in :

So it contains the methods increment and iincrement, that can be called, through the network, by the client :

Compiling the classes and the interface is not enough, we have to generate a stub class, to be downloaded to the client at runtime.

In an MSWin console window in the directory where the RMIServer.class is, we issue this command.

Two files are generated :


  RMIServer_Skel.class ( only for 1.1 )

In OUR example we COPY the stub file to E:\NETFILES .

To test our code, we first start the RMI registry, that acts as a coordinator,....

WITHOUT A CLASSPATH !!!, and you shouldn't even be in the directory where the RMIServer_Stub.class is .

We start the server.

The server's main method is started, where java.rmi.RMISecurityManager is appointed security manager.

An instance of the class is constructed,....

so its constructor is executed,....

where the superclass's constructor is called, this is crucial.

and we save the reference as a reference to the interface !

Then we register the server in the RMI registry, so a client can find it.

( rebind is a static method in java.rmi.Naming )

When we start the client RMIClient,....

WITHOUT A PATH to the stub file !!! ....

its main is executed.

Just as the server did, it appoints an instance of RMISecurityManager.

The java.rmi.Naming.lookup method is used to find the server.

This method returns a java.rmi.Remote reference, but we need an IntPhase reference, so we cast it to IntPhase, that is implemented by RMIServer.

With this reference we can call the server's methods .

The number 5 is copied to the server through the network,......

and what the method returns, is copied from the server to the client.

To illustrate that objects can be transported too, we have a second method that returns an object.

icnt now refers to a local copy of the Integer object.


Any type can be transported as parameter or return value, provided it's

- a byte, short, int, long, float, double, char or boolean.

- a class that implements ( many core classes do this, like java.lang.Integer )

- a reference to a remote object (this can then only be used for calling remote methods)


We have to use a policy file,....

because SecurityManagers have been set.


The stub file that we generated earlier by using rmic , is copied to the client at runtime,......

because the server knows where it is .....

and server and client are both allowed to access the file.

This applies to a local network, where you can use the file: protocol .

If you want to use http: instead, you start the server with this option, where the netfiles path, containing the stub file, is known to the HTTP-server (Apache f.i.) ,which has to be up and running.

The HTTP-server will then copy the stub file to the client when needed.

The policy file to be used by server and client then looks like this.



Some stations require an active Internet connection for this to work, even when only testing locally !




The netfiles directory and the HTTPserver path netfiles contain only this file :


The client directory contains only :
r.pol and rh.pol


A server class has to extend java.rmi.server.UnicastRemoteObject.


The interface extends java.rmi.Remote .


Its remote methods, those that can be called by a client, must throw java.rmi.RemoteException.


rmi: localhost and the port number 1099 can be omitted from the String, they're default.

(Same goes for the lookup call)

Instead of localhost you can refer to any host that has an RMI registry running with associated RMI servers, which makes this such a powerful model.

You refer to a host by its DNS name or its IP-address.

If the RMI registry listens to another port than its default 1099 , you'll have to specify it :


MSWindows example


Don't forget the trailing slash to indicate a directory .


MSWin syntax : backslashes .