Eclipse, JSR-198, SWT and Swing
This is an ancient blog post originally published by Brian Duff on 3 September 2003 on Radio Weblogs, and rescued from the Wayback Machine.
JavaGeek mentions that Sun might be joining the Eclipse board (from the related Yahoo News Article)
JavaGeek maintains that JSR-198 is incompatible with Eclipse. This isn’t so — there’s no technical reason why extensions written using Swing (the standard graphical toolkit that’s part of the Java 2 Standard Edition platform) can’t run inside Eclipse. Indeed, IBM are working with Oracle and pretty much every other application development tools vendor in Java to make sure JSR-198 will work. JSR-198 will be a Very Cool Thing Indeed for vendors writing application development utilities. If it were to exclude Eclipse, it would have failed in its goals. The onus is on Eclipse itself to make sure this doesn’t happen by ensuring that the JSR defines an API that makes it technically feasible to integrate compliant extensions into that IDE.
A fair proportion of the Eclipse vs. Everything Else argument boils down to SWT. What’s always bugged me about SWT is this: there’s nothing technically bad or wrong with it in principle. It’s just that it seems to have entirely bypassed the Java Community Process and has attempted to introduce a UI toolkit into Java that’s not part of the core platform. This is fine to begin with, but it’s time to start looking beyond Eclipse…
Having hacked out an inordinate amount of Swing code over the last six years or so, I’m thoroughly aware of its shortcomings. I even started the WinLAF project to encourage Swing developers to share Windows look and feel fidelity workarounds with the community. I know it has its problems, but let’s face it… Swing is part of the Java 2 platform. It’s standard. SWT is not. It’s not something the whole community has agreed on. It’s something IBM have developed and promoted outside the normal process. You’ve got to ask why this is.
To me, the most obvious answer is this: IBM should submit SWT as a JSR. Let the community decide whether SWT is the UI toolkit that will enable Java developers to create the next generation of desktop applications. The community should decide whether Swing should be improved or SWT should become the UI toolkit of choice. It ought to be up to us.
Notes from Future Brian, who is cringing both at my bad writing skills and weird opinions in this post :)
Something I’ve noticed in my experience is that the less defensible a position is, the more people tend to try hard to defend it with “obvious answers” and “let the community decide”’s.
I later got quite involved in working on JSR-198 which Oracle were leading along with Sun to try to build a unified plugin API for Java development environments. This wasn’t something I really believed in: I actually even at the time clearly thought that you’d wind up with a lowest common denominator that’d be fairly useless to anyone. But it was my job, and not something I could easily push back on. I did a good job of it in JDeveloper, and better still, it actually helped us modernize JDeveloper’s extension architecture, which led to bigger areas of responsibility for me.
As for the Swing vs. SWT thing… SWT was a fine solution to a difficult problem, and was superior to Swing particularly in terms of native fidelity and performance. Its programming model was more difficult than Swing. I was quite enamored of Swing, having used it since 1998 or so. This made me inherently hostile to SWT without really knowing much about it.
One thing I’ve learned to do much better in the years since is to not become entrenched in one particular solution or technology. I’m having a great time these days using many languages other than Java, for example, despite having been primarily a Java programmer for most of the last 25 years.
