Fixing JComboBox callbacks crashing linux Xorg

When debugging in eclipse on Linux, if a breakpoint is set in a JComboBox callback, this frequently (if not always) crashes Xorg. This is due to a Java and can be solved by adding the VM argument:


Interesting sort algorithm – SleepSort

I recently discovered a particularly interesting (albeit useless) sort algorithm called sleep-sort. The algorithm I read was implemented in bash so I thought I would convert it to Java:

import java.util.ArrayList;
import java.util.concurrent.CountDownLatch;

public class SleepSort {
	private static volatile ArrayList<Integer> sorted = new ArrayList<Integer>();

	public static void main(String[] args) {
		CountDownLatch latch = new CountDownLatch(args.length);
		for(String string : args){
			Integer num = Integer.parseInt(string);
			new AddToListRunnable(num, latch).start();
		try {
		catch (InterruptedException e) {
	private static class AddToListRunnable extends Thread {

		private final Integer number;
		private final CountDownLatch latch;
		public AddToListRunnable(Integer number, CountDownLatch latch){
			this.number = number;
			this.latch = latch;
		public void run() {
			try {
				sleep(number * 1000l);
			catch (InterruptedException e) {

This algorithm essentially takes in an input of a list of integers (could easily be modified to use doubles) and for each number, it creates a separate thread which sleeps for that number of seconds. After the sleep the number is added to a volatile List which, when all threads are complete is printed out with the numbers sorted.

While the sort is interesting for a number of reasons, there are also many circumstances under which it would not work. e.g. with a sufficiently large dataset with sufficiently small values where the first number may have slept and been added to the list whilst the last number has not yet had a thread initialised for it.

SerializationException on seemingly trivial RPC

Recently when invoking a somewhat trivial RPC that returns a POJO including a Map the GWT console greeted me with:
[WARN] Exception while dispatching incoming RPC call
Caused by:
Type 'java.lang.Double' was not included
in the set of types which can be serialized by this SerializationPolicy
or its Class object could not be loaded.
For security purposes, this type will not be serialized.: instance = 0.5

I was certain that GWT was capable of serialising a Double so I was a little baffled, it seemed that I had somehow, inadvertently tricked the compiler.

The solution was rather simple. Simply adding:

private Double dummyDouble;

to the POJO circumvented the error. It appears that as the compiler had no knowledge of that class containing any Double(s) it did not allow for the possibility that a Double may need to be serialised; adding a dummy Double variable forces the compiler to allow serialisation for that type.

Setting up globally accessible variables with tomcat

Tomcat is really great for deploying a maven-compiled gwt project; you just deploy the .war file and it works right out of the box! The problem with using a .war file, however, is that the web.xml file containing any servlet-config and servlet-context variables is stuck in that file and cannot be edited dynamically without a full re-compile.

In one of my projects I needed to be able to provide variables such as a remote host-name and port through the server config. There may be a better or more correct way to do this (reading a local file on the server is certainly an option) but this is the way that worked best for me:

Within the tomcat6 conf directory is a file called ‘context.xml’ : tomcat6/conf/context.xml

Adding an entry like this:

<Environment name="host" value="localhost"
type="java.lang.String" override="false"/>

to the file allows that variable to be globally accessible on the server side of the project.

This variable may then be accessed as follows:

String host = null;
try {
InitialContext initialContext = new javax.naming.InitialContext();
host = (String) initialContext.lookup("java:comp/env/host");
catch (NamingException e) {

Now global variables can be changed without recompiling the project and if the project has to be deployed multiple times, any customisation can be done by the client’s setup of tomcat.

Converting a gwt-maven project to a web application in eclipse

The main problem I had whilst trying to convert a freshly checked-out gwt-maven project to run with the google plugin for eclipse was that when I enabled the project to use GWT no entry point modules were available even though I had a well formed .gwt.xml file defining the entry point. As such it appeared that a little more needed to be done to be able to debug my project and step through lines of code with the eclipse debugger.

  1. Enable GWT for the project:
    Project properties -> Google -> Web Toolkit -> Use Google Web Toolkit
  2. Ensure that any extra libraries are loaded after the GWT SDK
    Project properties -> Java Build Path -> Order and Export -> Move 'Web App Libraries' below GWT SDK and Maven Dependencies
  3. Edit the Inclusion/Exclusion patterns in the build path
    Project properties -> Java Build Path -> Order and Export -> Confirm that the 'Excluded' pattern for $project_name/src/main/resources is (None)

After these steps are completed, you should be able to run the project as a web application:
Right click the project -> Run As -> Web Application
which should allow you to choose an appropriate entry point.

GWT Maven bindAddress

The gwt-maven-plugin happens to have a rather handy element that can be included in order to allow remote access to an application. The following allows the project to be accessed from systems other than localhost:


This line should be added within the <configuration> element in the plugin, thus allowing remote access to the web application (although not in hosted mode as far as I can tell) without the need for supplying any extra VM arguments .

Eclipse .snap files

With enough time spent using Eclipse IDE (64 bit, Ubuntu Linux) it has invariably crashed on me repeatedly. I am generally consistently save my work at the end of almost every line of code so losing work is not really an issue. The issue is, after crashing, Eclipse frequently refuses to load up again, just getting stuck on the “Loading Workspace” splash image.

It seems that although this problem appears to be quite prominent, a solution was not that simply to come by. The best solution I have currently found involves the workspace .snap files. A quick search for what a .snap file actually is revealed:

*.snap files represent the changes in workspace state of the IDE during the runtime. This is mostly for eclipse crash recovery plan. When a crash happens these files are used to recover the state of the eclipse workspace.ref

Thus in order to fix my crash I had to do the following:

cd workspace/.metadata/.plugins/org.eclipse.core.resources/
rm -f .snap

This would essentially remove any record of the last eclipse session (in this workspace) and no longer crash eclipse on the splash window/loading screen.