Project Matisse: Some Comments
My intent in writing last week's entry on Project Matisse was not to start a long-running debate. And I certainly don't want to start a flame war. So let me begin by thanking all those who bothered to add a comment; as mentioned I have no interest in a big debate, but I do like seeing comments. From what I can tell the comments came from well-intentioned people who are knowledgeable on the topic. Some of them appear to be more knowledgeable than me.
So while I have no interest in trying to change anyone's strongly-held opinions or beliefs I do, however, want to respond to some specific comments with a few clarifications and opinions of my own.
1. Where's the instance reuse gone from borders.. If every component on a large app has a new border how much slower will that make the UI creation? How much extra memory will the VM use. (teilo)
Creating a border is a fairly light weight operation, but the comment is still valid. I've put in a bug entry to request a change.
2. The bundle is looked up each time and not cached. (teilo)
The ResourceBundle class has its own cache, so it seems like putting another cache in the application would not only be unnecessary but inefficient.
3. And my pet hate is it's yet another builder that won't let you hand tweak the code. (teilo)
Strictly speaking that's true, in that you cannot directly edit the generated initComponents() method, but there is more to the story. At a high level you have access to all the components so you can do whatever you want outside of the generated initComponents() method. In addition to that, the NetBeans
4. So, why, in 2005, over a decade after NextSTEP, are we still generating source code from GUI builders? (lordpixel)
This issue is crowded with land mines, so please keep in mind my comment above about not wanting to start a flame war. The comment sounds similar to a question I got at the Austin Java User's Group meeting: "Why generate code at all?" In a follow-up discussion the gentleman who asked it described the approach used by Apple's Interface Builder. I put the question to Tomas Pavek, one of the lead developers on Project Matisse. In his answer he acknowledged that in theory a resource-based approach sounds better, but in practice things are not so simple. His complete answer was:
This is the old story "UI as code" vs "UI as resource", or "procedural" vs "declarative" UI definition. If we had nice and standard resource formats for the UI (which other platforms usually have), we would not need to generate the code (just some binding). Serialization is not so good for this purpose - mainly because we are often not able to instantiate everything at design time as at runtime. It is also not capable of accommodating meta data the GUI builder needs to store. And also Swing is designed primarily in a way that everything is naturally better expressed in code than declaratively (the component approach is not used consistently and clearly enough). On the other hand, we can see a lot of projects trying to develop some declarative (resource) format for describing UI. Both approaches have their pros and cons. Usually the declarative (resource) way is considered the right one - as the UI should be decoupled from code, etc. But the practice is not so clear.
5. Think of it this way, if a business has a bad process and we automate it... it's just bad faster. More on TOOLS: http://www.hacknot.info/hacknot/action/showEntry?eid=76 (netsql)
This is a link to the Hacknot article on why GUI builders should be avoided. The article is very well written. I do not agree with some of its conclusions, but I admire the quality of the prose. One of its main arguments is that GUI builders lock you in to a tool. That can be true but it should be pointed out that with the NetBeans form editor you have complete control over that lock-in. The tool creates two files: a .java source file and a .form file with metadata. If you decide you are tired of the lock-in just delete the .form file. The remaining .java file is yours to keep and do with as you will using NetBeans or any other tool. After all, it's just Java code. I have used NetBeans this way when creating applications. In those situations I am essentially using the form editor as a visual "keystroke macro" so that I don't have to type in all that code. More thoughts on the Hacknot article are available in an excellent blog entry by Ben Galbraith.
6. If you have a good layout manager (I use Explicit Table Builder), layout work will be neither tedious nor error prone. (griea)
Perhaps. But without tools it will still be a manual process. And that manual process is what I am trying to avoid. Ben Galbraith makes the point very well in the above-referenced blog entry: "... the domain of GUI design is, err, visual, and doing design by writing code either means you've got to get to the point where you can reliably visualize what your layout manager does in your head (emphasis on reliably, folks), or you wind up compiling and executing over and over again doing minor/major tweaking until you finally get it right."
In the end, we can discuss all day which way is the "best" and no one will ever change their opinion. Which is why having a choice of many techniques and tools is so important. Project Matisse provides yet another choice in the tools for building a Java GUI.