Tales from the desktop Java crypt
Some fascinating (and tragic) stories are emerging thanks to Steve-o’s dissing of “Java” (by which he really meant Java desktop interfaces, we hope).
First, about Lighthouse Foundation Classes:
We developed an Openstep-like framework in Java to make porting [of our software suite] easier and for the most part we were successful. The Lighthouse Foundation Classes (LFC) were not an exact implementation but they were close enough to make porting more of a mechanical process. […]
It quickly became evident that the people involved from the JavaSoft side had little to no experience with OO and/or GUI programming. I realized that if these were the people in charge of implementing the GUI toolkit for a platform, then the project is going to be a mess. Various design discussions ensued with the people who didn’t have any real experience with OO programming or developing and shipping real desktop apps overriding those who did.
Wow. That also helps explain “Model 2,” Sun’s horrendously destructive misinterpretation of MVC in the context of a single request cycle. Compared to that thought virus and the subsequent “enterprise” mania, Swing is a resounding success. But only compared to them. With resource based interfaces in the wild since the late 1980s, there’s really no excuse for Swing’s naive “put my progress bar in this window, somewhere” method of interface construction.
And next, Internet Foundation Classes:
Constructor, to this day, is still the most IB-like 100% Java-based interface builder I’ve ever seen. For 1996, it was f’ing amazing. (I wish I had a screenshot; I don’t.) It was IB, in Java. WYSIWYG drag-and-drop layout. Palettes. Dragging connections between objects. […]
Imagine this: IFC looked a helluvalot like AppKit, in Java. No AWT. And it came with a friggin’ Interface Builder!
IFC. Boy, does that name take me back. I did a project with it in the summer after my freshman year. I do not remember Constructor. I don’t really remember anything about IFC, except that in hindsight my application was way cooler than it should have been considering my experience. My junior year I made something in Swing that was really lame. Go figure.
Codercomments
On resource based interfaces:
why can’t you treat the builder’s generated code as a resource? Why XML (or something else) is better than Java to describe a GUI? You don’t need to look at Matisse or JFormDesigner’s code…
Inevitably, you do have to look at all code as code. I’ve seen at least one very talented programmer give up on fixing Matisse-generated code for a certain DVD() player interface and rewrite it by hand.
You just don’t have that problem in platforms with good resource runtimes and interface builders like Cocoa/AppKit. They don’t have “debates”:http://www.javalobby.org/java/forums/t85241.html between people over generated vs. hand-coded vs. XML() because everyone is very pleased with the native resource format. They’ve moved on.
Maybe being good at code was the problem…? I build NB Rich Client Platform apps with very rich UIs almost everyday now, and never look at Matisse blocks. Never even unfold those blocks. A designer (i.e. she doesn’t code) is building GUIs with us, too.
Maybe you should try Matisse/GroupLayout yourself (if you haven’t) and I should try Maven… ;-)
That’s fair I guess. :) I’ve never used NetBeans’ GUI builder and I have more experience in Cocoa than in Swing. I would still maintain that the variety, reputation, and quality of Cocoa desktop applications have proven resource-based GUIs in a way that code-generated applications have not. Not yet anyway.
Well, I have to write a complicated desktop app in Java so it runs on Windows, Mac OS/X and Linux, so I’ve been using NetBeans and Matisse. I targeted Java 1.5, used Absolute Layout instead of Group Layout, put all my visual elements in frames to keep them together (and not worry about window resizing, I know, it’s a cheat but it worked)…
And Bob was my uncle! More or less… At least, the app works and is pretty stable.
Oh, heh heh, I forgot: my POINT is, if you have to target multiple platforms, you’re not going to be doing it in Cocoa!
Besides, people complain all the time about generated code, but if you don’t fiddle with it, and concentrate on your application code, it usually works pretty well.
I mean, really – who cares how ugly it is? You can split hairs and complain that the code is “ugly” or you can assume it’s just compiler output (like object code) and focus on what you’re actually working on.
Isn’t it faster to just let Matisse do its stuff and focus on the work?
I’m sure Matisse will always be improving, but it’s my belief that using data to describe layout is a superior approach to generating or writing layout code. A GUI toolkit being cross-platform is a separate question. Cocoa used to be, when it was NeXT’s Yellow Box. IFC was cross platform, and Swing could (should!) have been a cross platform resource based interface toolkit. At least one is alive and well: Glade is cross platform and even cross language.
But I can see how Matisse is the best option for a lot of purposes, and I’m glad you’re happy with it.
Add a comment