Friday, April 22, 2005

Swing fighting back

Being a veteran Swing programmer and a recent Eclipse plugin developer, I seem to have seen either side of the UI toolkit war.

I have a few interesting observations I would like to share.

Swing Knowledge
We have been trying to hire a few developers with past UI experience (Swing experience is more easily available) but I am apalled at how little the people we have talked to know about Swing. Most people seem to hack in a UI and know just about enough to manage to get the UI working. How a renderer works and what you can and cannot do with it is not understood. Neither did these guys understand that you can write your own TableModel implementation and wire it to your data model and it doesn't have to always be backed by ArrayLists or arrays. I agree that these are not the most knowledgeable Swing programmers out there but when they see a DefaultTableModel they just do whatever they need to to populate it and get their JTable working.

JFace (MV framework over SWT) on the other hand enforces an interface such as a IContentProvider (this has its own limitations though) which needs to be implemented and keeps the model to itself. This is interesting because people then don't think in terms of populating Vectors but consider returning their business objects. I suspect that this might really help in writing better models to their UI. I haven't been able to verify this because of the complete lack of SWT profiles that we have received.

Swing's fight back
I have done a lot of Swing programming in the past and this goes past the regular hack-a-UI. I have been involved in several interesting Swing UIs (IDEs, applications, etc). I have had my share of issues with Swing but over time you learn to work around them. SWT definitely looks good and there are enough articles describing the virtues and problems with either. What is really nice is to see how strongly Swing is fighting back. Several Swing developers are openly defending false accusations (primarily performance related) and there is serious effort at fixing other issues that have remained unfixed over years (probably because there was always something more important to do).
  • NetBeans is being treated by Sun as their flagship Swing product and the competition has really done it (and Swing) a lot of good.
  • Take a look at the new Desktop Java features.
  • Some very important perceived performance fixes such as this.
Swing Performance has been steadily improving and this is an interesting comment on the EclipseWiki
For most of the time that Eclipse was under development, all of the above were very true. It has only been a very recent development (~JDK 1.4) that Swing has gotten fast enough to be acceptable. The look and feel emulations built into Swing are still lacking in terms of platform fidelity (although this is mitigated somewhat by the existence of high-quality 3rd party Swing look and feels).
available here.

All in all I think we'll see very strong improvements in Swing over the next few releases. I am really looking forward to it.

Swing Image
What has still not happened and I am hoping that it will be fixed in the future is that Sun should make sure that any UI they dole out is really good and this also goes for things like Windows Control Panel Java Applet which doesn't look very polished. Sun cannot have any excuses for shipping badly designed UI. Swing's image is affected by such UI and it can potentially undo (to an extent) all the hard work being done.

Check this list of Swing best practises out.


David Hall said...

Is there a particular location in which you're trying to find UI talent?

Anonymous said...

Do you have a reference to wiring the object model to the table model?

mati ( said...

I am a Swing developer from Poland with 3 years Swing expierience. Where are you looking for developers?

What company is hiring?

Neel Mukherjee said...

Hi Sachin,

I didn't know you were looking for Swing developers. I interviewed with Pramati back in December, and Lokesh who conducted this, clearly told that the current vacanies were for J2EE(product out sourcing) etc.

Anyway your observations on Swing are to mark I must say, but having said that, if I ever have to build a download manager gui I would always go for SWT.

The biggest perception change regarding Swing apps with users, will happen post JRE1.6.

The reasons are

1.Direct3D and OpenGL based painting optimisations.

2.More truer Native Look and Feels. Including support for Longhorn.

3.Improved text quality and capabilities

Read about the planned enhancements here.

Desktop Java Features in Mustang.

A shameless plug
Connectiva Systems is looking for Swing programmers at their main development center in Calcutta, India.

If developing a Graph Editor Environment, a Dashboard full of meters or a home grown Eclipse like plugin framework sounds challenging enough, come right in.

Sachin said...

The position(s) are in Hyderabad, India for Open Edge division, Progress Software Corporation (

Neel, I am no longer with Pramati. As a part of a BT I am now part of Sonic Software. I don't think Pramati is currently looking for Swing programmers however Progress (Sonic's parent company) is. If you are interested in knowing more drop me a note anytime (sachinh at sonicsoftware dot com).

SWT has its merits - especially in the area of L&F. Would be nice if they could interoperate better.

Thanks for your comments.

Anonymous said...

For interoperating swt and swing, check out

SwingWT combined the advantages of swing and swt for a better platform.


Ashish said...

Hey Sachin,

Welcome back. Does it really surprise you that Sun hasn't put enough research in UI, especially after you have worked on J2EE for quite some time now ? I personally feel, Sun is not quite interested in investing their resources in UI development. They seem to target the J2EE market and hence lot of improvements in Java and J2EE but only slow and stead improvements in SWING. I think thats why IBM is insisting on Open Sourcing Java.
From my limited experience with JVM and Swing I feel Sun should come out with another specification specially for UI development like they have split SE, EE, and ME.

Sachin said...

Hey Ashish,

I cannot agree with that statement that Sun did not put effort into UI research. To me, it looks like Sun put a lot of effort at the client side. Whether their results are equivalent to their efforts is another story. :-) Perhaps MS put in as much effort (or maybe more) and got more bang for the buck.

Take a look at the richness of the client framework. Swing itself is a pretty comprehensive UI framework. This came on the heels of AWT. Then there's Java2D and Java3D.

I am not sure you can compare Swing and J2EE though. Swing is a central part of the JDK and therefore follows the process that the rest of the JDK follows (through JCP). However, it would not help to have multiple implementations of Swing (not as much as it would in J2EE). Swing is not about choice of UI toolkit. It is about UI WORA. J2EE on the other hand is about freedom of vendor lock-in. I think developments in Swing are more or less in tune with the rest of the JDK. We have been seeing consistent improvements in the API, framework, widgets and importantly performance. In fact, the VM also supports a -client switch to enable Desktop Java applications to be more responsive.

I agree that J2EE has more attention focussed on it but that is because it is critical to a lot of companies' bottom-line. Also, Java is more popular on the server side than the client side. I am not sure I care too much for IBM wanting to open source Java. I think Sun's doing a fine job.

What is great about SWT and Eclipse is that they have brought a lot of attention on Swing. And this competition is making Sun invest a whole lot more into Swing.

Thanks for your comments!
And it is good to be back! :-)