Posts Tagged ‘swing’


Writing a Thick Client Java Application with EXTJS

October 20, 2010

update: example application

I have been writing thick client applications in Java for a while now. You can produce nice applications with Swing if you know how to and have the right tools and libraries at hand. Lately, however, some of our clients made me rethink the approach for thick client development. We were asked to develop a thick client application for Windows, Mac OSX and Linux. The customer also pointed out that in the future they would like the same application to be web based. This made me rethink the Swing strategy and bring back an older concept we developed for a customer back in 2000. The project is still online at It’s an online carpet configurator allowing the customer to color and custom order a carpet. The project was initially delivered over the web but was also distributed to stores on a CD, allowing the store owners to run the application on a local computer without an internet connection. The approach taken was simple: an autostart executable on the CD runs a webserver as well as a web browser without navigation bars, etc, as one application. To the store, the application looks like a thick client, on the web, it’s just another AJAX style web application.

Back to 2010, we know have libraries such as EXTJS that bring an application look and feel to your web application. Out of the box, EXTJS supports more feature rich components than are supported by Java/Swing. Firefox is a great browser and the mozswing project allows you to bundle Firefox into your Java/Swing application. if you combine this with an embedded web server such as Jetty you can write and deliver a thick client application the same way you deliver a web application. The hybrid approach allows you to handle parts of your application such as file dialogs, etc in Swing. Once a user selects a file to load, you can make a javascript call from your Java/Swing application into the MozSwing browser window to communicate back to your local web server to load the file.

Using this technology stack allows us to deliver a rich thick client experience and at the same time reuse most of the code, apart from specific features such as file dialogs.

The following is a screenshot of the current application we’re building:

Please let me know what you think about this approach. If there is enough feedback I’ll follow up this post with an example application for you to play with.

An example implementation can be found here


Catching all Runtime Exceptions in Swing

March 30, 2009

[note: see my post about writing a java thick client applications using extjs]

So you got some framework that you are using in your swing application and it throws a runtime exception. The Exception is thrown all the way out and ends up on the system.out – very nasty, not good looking and doesn’t help us determining that there is a problem in our application. We might just go on and do the same task again even though the exception was telling us that something went fatally wrong and that it probably would be a good idea to change the state of the application, go into recovery or terminate gracefully.

What can we do to prevent this? We can use try/catch clauses all over the place whenever we call some third party code but that is neither fun nor good code. And still there can be some exceptions slipping by – or are you really sure your code never throws a null pointer exception? Really?

There is an easier way to deal with this problem: All swing activity originates from the event queue and therefore all events are thrown to the event queue as well.  So in order to catch all runtime exceptions such as a null pointer exception we can just use the event queue.

We just need to extend EventQueue and overwrite the dispatchEvent method.

class EventQueueProxy extends EventQueue {

	protected void dispatchEvent(AWTEvent newEvent) {
		try {
		} catch (Throwable t) {
			String message = t.getMessage();

			if (message == null || message.length() == 0) {
				message = "Fatal: " + t.getClass();

			JOptionPane.showMessageDialog(null, "General Error", message, JOptionPane.ERROR_MESSAGE);

The proxy class still calls it’s parents dispatchEvent method and catches anything throwable. When it does, it pops up a simple dialog.

Only thing remaining, we need to install our new event dispatcher on the event queue.

EventQueue queue = Toolkit.getDefaultToolkit().getSystemEventQueue();
queue.push(new EventQueueProxy());

Using this method one can also use exceptions to handle errors throughout a swing application – dealing with errors and exceptions ends up at one place in the application this way and can be used to transform the exceptions into human readable error messages.

For some other helpful links for building swing applications have a look at helpful-java-swing-articles


Helpful Java Swing Articles

August 5, 2008

I have been doing java swing development for the last few years – whenever I start a new contract job on an existing swing project I am usually amazed that people working with swing have never heard or seen these two articles on

  1. closure style actions
    Make sure you are not writing tons of inner classes to handle your actions or even use a global event handler
  2. modify swing when the components are added
    This is great to style a component when it is added to the UI according to the operating system or make a change to a component without having to implement it for every look and feel that you support

These two articles can be a great starting point to make your life developing swing easier.