Scruffles.net: Swing and Vendor Lock-in

Tuesday, February 6, 2007

10 years ago Sun introduced Swing, and with it, JavaBeans. JavaBeans were supposed to allow UI widgets to be defined as components. It would allow Swing developers to take advance of graphical layout editors without vendor lock-in. It failed.

Those who tried to develop Swing apps with their IDE's drag and drop editor forced their way through limitations and learned how to hand-code fixes that wouldn't break their IDE's code parsing. Then support would dry up for their favorite tool and they would be left with no alternative, but to hand-code their Swing apps. Others recognized the graphical tools as Microsoft-style lock-in and avoided it early on. For almost a decade, hand-coded Swing apps have been the norm.

10 years later, Sun is trying again. They seemed to have missed the point of their initial failure. They seem to be under the impression that had the first tools been of higher quality, people would have never resorted to hand-coding their Swing apps. In reality, it was the proprietary nature of the IDE-generated code that caused the failure. No matter how well the tools would have worked, Java developers have been conditioned to demand vendor neutrality.

Vendor neutrality is not something developers get from Netbeans and Mattise. As nice as the platform is, the code it generates is not parseable by any other platform. Because it doesn't generate code to a standard, such ad-hock compatibility wouldn't be enough anyway.

This problem has already been solved, of course. Ironically, one of the latest solutions is from Microsoft. Although XAML is a closed standard, it is a standard. It's well defined and parsable by multiple editors. A Swing solution wouldn't have to be as feature heavy as XAML. There are many open source solutions that fill the need. Of course they would need to be adoped by Sun (presumably via a JSR) and the IDE vendors to be a useful vendor-neutral solution. Until this happens, Mattise is just another way to lock your application to your IDE.

Labels: Programming

3 Comments:

You seem to forget that the generated code also has a xml-based .form file near-by that would make any programmer happy.

So you just need to parse the actual code for actionperfomed and such, which should be quite easy since you have those marked regions.

GUI-from-XML has always been an idea but never a solution in the Java world. Something like Glade, the XCode forms or whatever Microsoft is suggesting sounds nice in theory but they just never get it right.

By Emilian Bold, At February 7, 2007 at 2:38 AM
I'm not asking to be able to parse the generated code. I'm asking to be able to edit my GUI in Netbeans on Monday and then edit the same GUI in JBuilder on Tuesday.

Yes, Netbeans has a .form file. So does IntelliJ IDEA. But they aren't the same format. Yes, Netbeans could have adopted the XML format used by IDEA, or IDEA could have adopted the one used by Netbeans. But they didn't.

Until everyone sits down at a big round table and agrees on a format, all GUI designers will continue to be proprietary.

By Bryan, At February 7, 2007 at 6:42 PM
Swing was really born as a hand-coded solution for UIs and many years of trying to "frankenstein" it to visual editing have not solved that. The "Autonomus View" spoused by swing tutorial also makes difficult testing, difficult to separate UI code from business code ... Swing being as it is, the only sensible solution would be to have a "desing view" at RUNTIME, so as to tweak UIs, layout etc (this view could or could not be available to end users, but it is needed for developers) ... The "obsolete" view that UIs are just some kind of static forms is not suitable. Smalltalk (Squeak), Oberon (System 3) have used this to offer useful tools for UIs (not just APIs, and code that works through endless tweaking).

By Anonymous, At June 11, 2007 at 6:33 AM

3 Comments:

Previous