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).
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.
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.
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.
