Demystifying JINI: Dynamic Code Download

In the 1st part of the Demystifying JINI series, we had explored how to write a bare bones non secured client/server:

In the 2nd part, we had shown how to Spring-ify it:

In the latest increment, we will explore how to handle dynamic code download.

I have been working with JINI for the past couple of years. And the more I explore its features, its versatility, the more I come across new ones. This project was built with the famous “Eight Fallacies of Distributed Computing”. So, needless to say, it does not disappoint in terms of scalability or reliability.

Why need dynamic code download?

At the heart of JINI lies its flexibility. It decouples the interface from the implementation (of the Proxy), and makes it independent of the transport protocol as well. All these details are transparent to the end user.

However, there needs to be a way in which the Stubs are downloaded. These stubs will actually help the remote client to connect to the server, and make calls on the remote JVM. This is where dynamic code download is needed. And this comes out of the box with JINI.

Why should I care about dynamic code download?

The dynamic code download is a very powerful feature. In normal client/server distributed architecture, the client and the server agrees on a common API. This is commonly known as the shared module, be it JEE or RMI. And it is mandatory for us to bundle the shared module with the server as well as the client modules. Otherwise, the application will blow up with hosts of NoClassDefFoundError-s.

But, with this interesting feature in JINI, the client does not even have to depend on this shared module at all. The reason is, it can be downloaded when doing the lookup. Of course, every feature comes with its costs, and in this case, the only downside to this is, we need to use reflection to query the remote service. Either that, or use a scripting language like Groovy.

How does it work?

To enable dynamic code download, we need to specify the code base property (similar to the Applet’s) on the JINI server. When the client connects to the server via lookup, this will be available to the JINI client. In its simplest form, it can be as below:

System.setProperty(“java.rmi.server.codebase”, http://localhost:8080/rmi-service-api-1.0.jar);

This should be called while starting the JINI server.

Getting started

Download the folder:

cd into it and first start up the reggie by using the ./

Then, again, we need to start a http server to serve the jars for dynamic code download. Use the ./ to start that server. This server starts at port 8080 and makes any jar placed inside of the service-interface directory, available over http://localhost:8080. This is a small utility provided y JINI, in production, we would need a more secured web server.

The Service API

The API jar is built and put in the service-interface directory above to make it available for dynamic downloads. Note that it is bundled with the Server, but not with the Client.

The Server

We have built this on top of the Spring-ified server that we saw in part 2.

Note that its is almost similar, just has the extra line setting the rmi-codebase property.

The Client

Since the client does not have the API as its dependency, we have to use reflection. But remember to use the RMIClassLoader to load classes from the API jar. Let us demo a Swing app which uses the remote BankDetailService to fetch data to be displayed on the JtreeTable.

The Main Class

The Method to Query the Remote Service


The sources for the server be found here:

The sources for the client be found here:

You can download the sources and then run:

mvn clean install -P create_dist

This will create the distribution inside the target/appassembler directory. You can go inside the appassembler/bin directory and run the ./launch_swing_app to launch the application.


Jan Newmarch’s Guide to Jini Technologies

Leave a Reply

Your email address will not be published. Required fields are marked *