Category Archives: jini

Using SwingWorker to update Swing Components asynchronously

I have a JList, the contents of which are updated asynchronously by a different thread. The way I update the JList is by updating the model:

The only problem is, if this is not done in the EventDispatchThread, the UI becomes unresponsive, and starts behaving weird.

The way to solve this to use the SwingWorker.

I have a Jini server, which streams data to a Jini client, in this case, a Swing JFrame. I have a JList to which I publish the data as and when it becomes available.

Jini Service API

Its a simple streaming service:

At its heart is the interface RemoteDataListener, on to which the server publishes data as it becomes available.

Client Implementation

The key is to implement the interface RemoteDataListener along with the SwingWorker as shown below as an inner class in the JFrame:

We invoke the long running service in the doInBackground() method and add itself as a listener. When new data is received in the newData() method, we immediately call the publish() method, which delegates it to the process() method. The process() method is invoked within the eventDispatcherThread. This ensures that any updates made to the model of the JList is reflected on the UI. So, the code to update Swing components reside here. Also note that the done() method is called by the SwingWorker after the processing thread is finished.

Running the example

Run the SpringNonSecureRmiServer to start the Reggie and the Jini Server. After the Jini Server starts up, run the RmiStreamingDemoFrame.




The sources can be found here:

There are 3 Maven projects under that:

  1. rm-api
  2. rmi-client
  3. rmi-server

Data streaming with Jini

Lets take a simple example of how we can stream data from a Jini Server to a Jini Client. Data Streaming means that we can send huge, unbounded data to a consumer. In this example, we will read from a DataStore and directly send it to the client.

We have the following simple api:

The RemoteDataListener is a remote call-back where the data would be published from the Jini server as it becomes available.

Note that this is a Remote interface as well.

Server Implementation

The server implementation is very simple: its a straight delegation to the Dao.

The Dao just pushes data to the RemoteDataListener as shown below:

Client Implementation

The trick really is in the client implementation. In this example, since the RemoteDataListener  is a Remote listener, it is an exported Jini service which lives on the client. This is an example where the Jini Client and Jini Server swaps roles and the client becomes the server. Just to illustrate our point, we have created a very simple client which just writes the data received on to the console.

Then, we have a simple class with the main method to invoke the streaming service:

Note that just before invoking the streaming service and passing the RemoteDataListener, it is being duly exported as a Jini service and the exported RemoteDataListener is then passed to the streaming service. That is the trick, really.

The SpringContextHelper is a simple class to load up Spring Context and help look up remote services:

Running the example

We have embedded the Reggie in, so simply run the SpringNonSecureRmiServer to start the Reggie and the Jini Server. After the Jini Server starts up, run the SimpleStreamingClient. You would see the following on the console:


The sources can be found here:

There are 3 Maven projects under that:

  1. rm-api
  2. rmi-client
  3. rmi-server

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

Demystifying JINI: Non-Secure Server: Part 2

In Part 1, we had sieved through the example available on the JINI site and distilled the Rmi client server code to the bare minimum. But still, its far from production ready. Its not Spring-ified yet. Lets try to do that here. We will build this on top of Part 1.


I need the following utility which can double up as a Spring bean, will do the export for me.

This is the main Spring configuration:

And, see how simple my main class has become, just loads the Spring file:


The client is a bit tricky, as I need to lookup the remote service from the registry. In Spring’s nomenclature, this is nothing but a FactoryBean.

The Spring configuration is:

And this is the way we can use it.


The code can be found in GitHub, under the code/jini/unsecure/plain:


Demystifying JINI: Non-Secure Server: Part 1


What is JINI?

JINI is a framework that enables us to write Java-based distributed systems. In simple terms, it allows you to expose Java classes as services, which can be then called remotely by other Java based clients over the network. For more details, refer to

How is it different from RMI?

  • In RMI, the client should explicitly know about the server and then make a look-up. But JINI has the concept of discovery, where it attempts to discover the service through some known search parameters.
  • RMI does not support distributed transactions or events, JINI has support for that and lot more.
  • RMI does not support dynamic code download from the server, JINI does. This means that the client is more loosely coupled and not necessarily tied to a particular protocol.

Where do I find it?

Its hosted at

Reason for this blog

I came across this in my current project and wanted to explore more about the hows and whys. The problem was acute shortage of documentation on the internet, probably because very few people use this. Also, the documentation and code sample available at the apache-river site were bloated and far from simple. They just created confusion. So I decided to write my own simple implementation using minimal amount of code and configuration.

Writing a bare bones, non-secure client/server using JINI

High Level Overview

Our implementation will consist of the following 3 components:

  1. The RmiServer: This will expose services which can be invoked as Java method calls across the network.
  2. The RmiClient: This will consume the remote services provided by the RmiServer.
  3. The Registry: This will act as an intermediary between the client and the server. The server will register the services its exposing, with the registry. And the client will do a look-up for the desired service from the registry. We will be using the reggie component of the apache-river project for our Registry.

Please note that to keep this simple, we are not using the dynamic code download feature that JINI provides. A downside of that is, the client also has to be bundled with the JINI-specific libraries at runtime. If you ask me thats not too bad actually.

 Setting up the Maven dependencies

Both the Client and the Server should have the following JINI-libraries dependency:

 Creating the Remote interfaces

We will have the following two interfaces which we will expose as services:

Note that these extend the java.rmi.Remote interface and also, each method throws the java.rmi.RemoteException exception. These two interfaces will be shared between the Server and the Client.

The Server

The Client

The Reggie

The reggie should be configured properly, and this must go hand-in-hand with the server. For example, they should use the same protocol, in this case, JRMP. If it uses JERI, then both the server and the reggie should use JERI.

This is the start config file for reggie [start-reggie.conf].

After that, we need the following file for specifying the protocol as well [jrmp-reggie.conf]:

Refer to the JINI documentation for the configuration details.

Putting it all together

To see this in action we need to first start the reggie service. Unpack the From the command prompt, cd into it and:

java -Djava.ext.dirs=lib -jar start.jar config/start-reggie.config

Then, start the server using the main method.

For running the client, you need to create a policy file [called policy.all] containing the following:

grant {

When running the client, give the following JVM arguments:

You should see the out from the remote server.


The code can be found in GitHub, under the code/jini/unsecure/plain: