Pretty print XML with Java

I have the following XML document all, in a single line:

All I need is, to pretty print it with nice tabs and all. This is the code:

This would nicely format it as below:

However, please note that it fails if there are spaces within the tags.

The source can be found here:

[Jackson] Json to Java Conversion with Ploymorphism

Converting Json String to Java Object is never straight forward, especially when polymorphism is involved. Consider the below interface:

It has two sub classes:

We now will try to convert a Json String to a Java Object:

The full test can be found here:

This will immediately throw the below exception:

The reason is, the Json String does not have any information about the specific subclass. This can be very easily overcome by forcing the type information while serializing Java to Json, by using the @JsonTypeInfo annotation. This should be placed on the interface or the abstract class as shown below:

Now, the below code would work:

The full test can be found here:

The entire source code for this can be found here:


[Sorting] IllegalArgumentException in TimSort

Sometimes, simple things like sorting are not simple. We were doing a sorting on a large data set containing around 2000 elements. Sometimes, when most of these elements had null fields, we would get a very weird exception:

Did a bit of googling, and found out this happens when the sorting implementation is not transitive.

The problem that we faced is really, reproducing this consistently, as it seemed to work in most cases and then starts failing seemingly randomly.

In this entry, I will try to reproduce this issue. Let us consider the below entity:


We would use the below comparator for sorting this:


We will try to sort a List<Person> with the above comparator:


This would fail consistently with the below data set:


The full test case is here:

Now, consider the below comparator:


The difference between the transitive and the non-transitive version is obvious. The real challenge here is having a data-set that fails consistently to cause the exception in TimSort.

The entire source can be found here:

Example of WebSocket/STOMP using Java

WebSockets enable 2-way, duplex communication between client and server. All major browsers and all major Java servers like Jetty 9, Tomcat 7, etc. support websockets. The present example has been done with Tomcat 8 as a server and a Tyrus based simple Java client.

Simple WebSocket Server

We will use the WebSocket API to create a simple Server.

Configuration: pom.xml

The pom would be the same as a typical JEE pom. Just put the following dependency:

Server Code

Simple WebSocket Java Client

Configuration: pom.xml

The pom would be a simple one, just add these following dependencies:

Client Code

Define an Endpoint:

Then invoke this:

Note that there is a 2-way communication from server/client. This is handled in the MessageHandler defined in SimpleClientEndpoint:

Spring WebSocket Handler Server

Though the above example is simple and good for starters, this is not practical. For one, it does not integrate with Spring. Lets build something more closer to the real world.


The client attempts to invoke the BankDetailsService asynchronously, through websockets. For this, it first initiates the request, sending the server the sort-order. The server then triggers a dao-call. Each time when a new row is read off the ResultSet, it is immediately sent to the client. After all the records have been read, the session is closed. Note that the messages are binary. Json strings are gzipped and then sent across the wire to save bandwidth.

We will use the Spring websocket module for integrating WebSockets with Spring.

Configuration: pom.xml

We would need the spring websocket module:

Spring Configuration

The ExceptionWebSocketHandlerDecorator is a decorator for handling any runtime exception gracefully by closing the connection.

Server Code

This is how the BankDetailsWebSocketHandler looks like:

Note that the actual action happens in DataListenerForStompHandlerImpl:

This class is passed to the Dao, and after each record is read from the ResultSet, it is sent to the client.

Client Code

Let us take a look at the client. We are still using a standard WebSocket client, not the Spring stomp client.

Like the 1st example, we have defined our Endpoint as below:

All subsequent messages from the server would flow into the MessageHandler defined in the above class. The above is now invoked here:

Source Code


Maven appassembler plugin: How to deal with path too long issue in Windows

Windows sucks! We all know that. Recently, I had one more reason to crib. I am using the Maven appassembler plugin to create a deployable distribution for my Rmi Server. I added a couple of more dependencies. And suddenly, the windows .bat file that is generated by the appassembler, suddenly wont launch. It was complaining that the path was too long!

Well, I visited the plugin’s home page and after struggling for 3 hrs, I was none the wiser.

Then, I chanced upon an article and with a little bit of tweaking, I was able to get it working. The trick is the following magic line:


Before the fix

The run_rmi_server.bat looked like:

After the fix

The run_rmi_server.bat looks like:

Note that the path has been shortened by using *. This has been introduced in JDK 6:

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

Using Jaxb To Serialize Java-Objects To Xml

Recently, I had a requirement of serializing some Java objects to xml. Though I had assumed it to be fairly straight forward, during implementation, I found out the hard way that it is not at all intuitive. The following are the ground rules:

  1. You need to decorate the class which you want to serialize with the @XmlRootElement annotation. This rules out having the flexibility of serializing a List or a Map directly. It has to be wrapped within a class having the @XmlRootElement annotation.

  2. Jaxb needs a default constructor. So if you have an immutable class with all fields set through the constructor, you need to provide a default constructor and set all the final fields to null.

  3. Though Jaxb works well with the List, it needs a custom adapter to serialize a Map with the @XmlJavaTypeAdapter annotation, as we will see. This is the single most pain point in using Jaxb.

The serializer code

I am using the O/X Mappers from Spring ( for marshalling. I found it very convenient, specially if I want to switch from Jaxb to say, Xstream. The code is pretty simple:

This is the version using plain Jaxb:

The POJO to be serialized

The POJO looks like:

Attempt 1

When I try to generate xml, I get a blank document:


The possible cause might be that since the object is immutable without any setters for the fields, Jaxb cannot figure out the fields to serialize. So, this time we will try to explicitly ask Jaxb to serialize the fields by adding the @XmlAccessorType(XmlAccessType.FIELD) annotation to the EmployeeGroups.

Attempt 2

The POJO looks like:

The 2nd attempt gives rise to the following exception:

Caused by: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
java.util.List is an interface, and JAXB can’t handle interfaces.
    this problem is related to the following location:
        at java.util.List
        at private final java.util.Map com.swayam.demo.xml.EmployeeGroups.employeeGroups
        at com.swayam.demo.xml.EmployeeGroups

This message is actually misleading. What it means is that its high time for us to write our custom adapter for handling the Map.

Attempt 3

The adapter would extend the XmlAdapter. It would consume a Map<EmployeeRole, List<Employee>> and return a concrete POJO, in our case a ListWrapper<SimpleMapEntry>.

The SimpleMapEntry represents an Entry in the Map, customized to our needs.

The ListWrapper is just a wrapper around a List, as Jaxb cannot handle a List, and needs a POJO to serialize.

At the end of it, the test runs without error, giving the following output:


Attempt 4

The adapter works fine, but since the members are immutable, we have to explicitly declare the fields to be picked up by Jaxb.

The test errors out:

ERROR [main] PlainJaxbSerializer.serialize(46) | could not convert rmi output to xml
 – with linked exception:
[com.sun.istack.internal.SAXException2: class com.swayam.demo.xml.jaxb.SimpleMapEntry nor any of its super class is known to this context.
javax.xml.bind.JAXBException: class com.swayam.demo.xml.jaxb.SimpleMapEntry nor any of its super class is known to this context.]
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(

Attempt 5

This simply means that when creating the Jaxb context, pass in the SimpleMapEntry as an argument:

All is good, and this is the output:

Attempt 6

Note that the employee node is still empty. We need to explicitly set the @XmlAccessorType(XmlAccessType.FIELD) annotation:

And everything comes as expected:

Attempt 7

The only problem as I see now is this:

It should be within an <employee>. The following is the modification needed:

With this, we get the following output:


The sources can be found here:


Using JXTreeTable to display grouped data

Let me start by ranting about Swing. Its a lame duck. It could never really take off. But we can’t live with it, can’t live without it. Especially if the application is a legacy Swing application written 10 years ago.

So, when I had the prospect of displaying simple grouped data, the fear of writing my custom JTree absolutely seized me. That is when i thought about the SwingX project. In its present form, it buggy, unusable, messed up etc. It took me close to an hour to figure out a stable release from the quagmire of broken links that Google came up with. At last, the Maven Central came to my rescue in the form of the following 3 magical lines:

The First 90%

After being associated with Swing for a good part of my life, I have come to believe that 90% of your job is done if you can create a good Model, especially for unwieldy components like JTable and JTree. So, I do the same for this as well. In this case, I represent grouped data with a Map<String, List<BankDetail>>. All I want is to display the groups as nodes and the Lists under these nodes. This is how I model it:

The remaining 10%

The tying up the model to the JXTreeTable is the simplest thing on the earth:

This is how it looks like:



The source code can be found here:

The main class to run is: GroupingDemoFrame.

I found the following post very useful in my efforts:

Using JDK 8 features to group data in a list

Use Case

Sorting has always been supported by Java. Recently, I came across a requirement in our project where we needed to group data in a list by some conditions, which can change based on the user selection. Traditionally, this would have been done by the sql statement’s GROUP BY clause in the DataAccess layer. But in our case, that would make the sql query very complex. So we decided to take the plunge and do the group by in the Service Layer using Java.

The Dao looks like this:

And the Service looks like this:

How to do it pre JDK 8

Pre JDK 8, Java does not provide group by out of the box. After ruling out hand-coding that logic, we decided to go with Google Guava’s ListMultimap. Its pretty cool actually. It stores in different values having the same key. Then, it exposes a List view of data with similar keys.

Note that we have to do it in 2 steps:

  1. Collect the data

  2. Iterate over the collected data and create a List view for each unique key

This sometimes becomes cumbersome, but is possibly one of the most elegant solutions pre JDK 8.

What changed in JDK 8?

Jdk 8 supports group by out of the box. No for loops, no 3rd party libraries. This is the code, short and sweet:

Again, note the absolute lack of for loops, which make the code crisp and more readable. Let me sum up how this is achieved:

  1. Create the Function for generating the key by which the data would be grouped. This Function would take a BankDetail object and supply a String. Note that the key can be any Object as long as it has a proper hashcode() method.

  2. Create a Collector using the Collectors.groupingBy() to collect the data

  3. From the un-grouped data, create a Stream, and apply the collector created above.

That simple!

The code can be found here:

Maven: Creating deployable distribution: Part 1: Using the Appassembler plugin


Often, we have a standalone Java application, from which we want to create a deployable distribution having all the dependencies in one place and with a shell script or bat file which can be then invoked from the command prompt. The Mojo Appassembler plugin helps do just that. We will be using the maven-distribution-example as reference. This project would need the project rmi-service-api to compile.

Using the Appassembler plugin

We have created a profile called all-in-one which can be called to create our distribution:

This profile contains 2 parts:

  1. The appassembler plugin
    1. Collects all the maven dependencies in the target/appassembler/lib
    2. Generates the  .sh and .bat scripts to invoke the main class which is provided
  2. The maven assembly plugin which creates a tar archive from
    1. The appassembler directory
    2. readme.txt file

The maven assembly plugin works using the below assembly descriptor (all-in-one-assembly-descriptor.xml):

Next, we invoke Maven by:

mvn clean package -P all-in-one

Go to the tar file is generated in the target directory. You will find two directories inside the tar:

  1. bin: This contains the shell script and the bat file
  2. lib: This has all the dependant jars

You can now run the Rmi Server by invoking the shell or bat scripts from the prompt.

The sources can be found here: