scruffles.net subscribe
Saturday, June 30, 2007

Bob Lee had some interesting comments on the advantages of using annotations rather than XML for configuration. I didn't find the original post as interesting as the comments that followed. Among them was a little pearl of wisdom I think deserves to be embroidered on a pillow:
Contrary to Spring's philosophies, I think very few design decisions are "a matter of taste." Some ways of doing things are provably better than others, and one way of doing something is almost always better than two. Otherwise, you end up with the Perl of frameworks.
Ok. So it would have to be a big pillow. But I've regularly had to deal with co-workers who write code with all public members or write extra methods that are never called -- just in case. They almost always plea 'a matter of taste'.

Tuesday, June 19, 2007

Josh Marinacci recently wrote about using a tool vs hand coding your Swing UI. While I don't completely disagree with all of his arguments, he tries to make a couple of points that burn me a bit.

1) He tries to argue that you don't have to worry about vendor lock-in with Matisse because its open source
2) Because the files generated by Matisse are hand-hackable, you don't need to be concerned with lock-in

In my 8 years of Swing programming, I've used 5 visual editors for writing Swing GUIs. While Matisse is currently the leader, I don't see any reason why it would still be the best next year. The previous 4 visual editors didn't last long, I fail to see why Matisse's open source license is going to keep it in the number 1 spot throughout eternity.

Also, each of the 5 visual editors I refer to generated hand-hackable code. While we could always survive without our old GUI tools, the crap code generated by those tools were never really maintainable.

While standardizing the XML format Matisse uses won't hurt anything, I really don't see how it would help either. It's not as if Eclipse, IDEA and JBuilder are all going to start playing nice with Matisse-generated code.

We need more than just a defacto-standard JavaBeans editor. We need a well thought out component model.

Bryan