Joshua Marinacci, Swing hacker, and new Sun employee has asked Why don't you ship Swing apps? His post has generated a lot of comments in the last week, and since everyone loves to complain, I'll join the fray.
My Jude documentation browser software would be a Swing application rather than a web server if Swing had a decent HTML renderer. In fact, it might be a Swing application if JTextComponent and the whole architecture of the javax.swing.text and javax.swing.text.html packages weren't such a mess. (Josh is the lead developers for the open source Flying Saucer xhtml/css2 renderer project, so maybe he'll be able to improve the HTML situation with Swing.)
Other gripes with Swing, off the top of my head:
- There are no decent layout managers. The sufficiently powerful ones use baroque layout methods and are really complex. Why is there no decent way to arrange basic rows and columns of components? This is my biggest pet peeve. (And one that I may some day make the time to address. There is a simple implementation of a column layout manager in Java Examples in a Nutshell that I'd like to extend and enhance.)
- The architecture is too complicated. JComponent simply has 10 times more methods than it should. In retrospect, I wish the Swing team had abandoned AWT compatibility and not inherited from java.awt.Container. (I wonder if it is possible to create a new component architecture that does not use Component, Container or JComponent, but that can use the component drawing code of the various PLAFs?)
- getContentPane() -- they've finally made this optional in Java 5.0, but we should never have had to call it at all. What a gratuitous roadblock to erect between the new Swing programmer had her first successful "Hello World" application! There are other, similar things, like why can't JTextArea handle scrolling without being manually placed in a JScrollPane?
Java on the desktop was clearly not a well-funded priority for Sun. If it had gotten the attention that enterprise Java had, we'd have a rock-solid core set of Swing components, including standards-compliant HTML+CSS rendering. On top of this we'd have a standard way to create a GUI from a textual description of it (like Mozilla XUL). And we'd components and frameworks for data-centric GUI designs, including an XForms implementation.
It's possible to make really nice apps in Swing, but you are right, some of the choices they made are highly questionable. What's most frustrating is that there is some unknown relationship between LayoutManagers and JScrollPanes that cause both to act unpredictably with high frequency. The getContentPane() thing, while annoying, is at least a knowable rule: "Always call getContentPane()". The sh*t with JScrollPane and GridBagLayout is just SOO frustrating because you cannot reliably guess at how it will behave.
Checkout java.net's JDIC for web rendering and JDNC for simpler API and XUL-like approach. Both soon worth writing a book ;-)
-Alexis
Alexis:
I did take a look at JDIC. But that is not an HTML renderer so much as a wrapper around a web browser. When I looked at it, there was no simple way to tell it "please display this String of HTML". I would have had to write my HTML to a temporary file and then have it display that file. Yuck. Also, it involves native libraries, and for simplicity of deployment, I don't want to go there.
Hurrah! That about sums up the major issues with Swing. SpringLayout is supposed to be simpler for rows and columns, but just needs tons of helper code to get right.
You should be able to specify a layout and components and event hooks in XML, like Qt's Designer, or XUL as you mentioned. JDNC just seems like another baroque layer on top of Swing instead of what could have been a simple intermediary between a form designer and code.
Look at what you can do with KJSEmbed.
http://xmelegance.org/kjsembed/examples/
If there was an equivilant for Java and Swing, the world would be a much better place.
don't blame sun... if they knew how to do gui we would all be running solaris today.
You know, not long after he started this whole thing, I went out for beers with Joshy and said almost exactly the same things.
The only thing I would add to the list here is that basic databinding is much too complex. If all the swing components had a simple option of "Bind this property of the SWING component to That property of this data bean" and it would take care of the property event change listeners and optionally give you an option to provide a translator (Take this ENUM/static final value and turn it into That Icon image) we would be worlds farther ahead of where we are now. Things also really should be collection aware in terms of things like selects and menus.
Coming from the J2EE side of the house, it amazes me when I try and do some SWING work that it is easier to get clean MVCish data binding with Struts than it is with SWING.
Have you checked out JGoodies? The FormLayout library and the Bindings library both help in simplifying Swing development to some extent.
"My Jude documentation browser software would be a Swing application rather than a web server if Swing had a decent HTML renderer."
That add depends on your definition of decent. Swing HTML rendering is much too slow and I wish Sun would open source HotJava. Still, when IE isn't good enough for Jude, you have a rather narrow definition of decent.
"In fact, it might be a Swing application if JTextComponent and the whole architecture of the javax.swing.text and javax.swing.text.html packages weren't such a mess."
Not that I really disagree, what APIs would you consider better? I don't mean to imply that you have to offer a better solution for your criticism to be valid. These things are hard to design clearly and I'm just curious.
"There are no decent layout managers."
That ship with the JRE--perhaps. There are an awful lot of Swing layout managers.
"The architecture is too complicated. JComponent simply has 10 times more methods than it should. In retrospect, I wish the Swing team had abandoned AWT compatibility and not inherited from java.awt.Container."
Have you looked at Buoy? Balise helps address the layout manager problem above.
Buoy
http://buoy.sourceforge.net/
Balise
http://balise.sourceforge.net/
Curt,
Thanks for your comments.
Jude doesn't run in IE because until recently it was a XUL-based application. Since I was locked into Mozilla for that reason, I didn't make my CSS compatible with IE. IE compatibility is on my list for Jude 1.1
I think the mistake with javax.swing.text.* was that they went for editable structured documents. I think plain-text editing in JTextField and JTextArea plus HTML rendering (but not editing) would have been a more reasonable feature set to tackle, and they could have done a better job.
Yes, there are a lot of layout managers out there, but if they're not part of the JRE, they a lot less useful. I'm disappointed that they couldn't have gotten better ones into the swing itself.