Scruffles.net

Optional Typing in Groovy

2009-04-14T17:11:00.005-06:00

Groovy has a feature called optional typing which allows types to be declared for fields, parameters and method return values despite Groovy being an otherwise dynamically typed language. This is a useful feature if for no other reason, than for interacting with statically typed languages such as Java. When Java calls Groovy code, it won't have to cast everything to its real type to use it.

While the feature itself is useful, the name optional typing, and how the feature is marketed is confusing and misleading. Many assume the phrase optional typing is short for optional static typing¹. However, static typing is a term reserved for compile-time type checking², and Groovy does none of that. This will actually compile (but not run) in Groovy:


int x = "I am not an int!"

I think the term optional typing should be abandoned and the books should be updated to be a little more honest. Programming is difficult enough without having to fight mis-information.

¹Groovy In Action specifically states this to be the case, with two pages of text on how to choose between dynamic and static types when writing Groovy programs: "The choice between static and dynamic typing is one of the key benefits of Groovy".
²While wikipedia is never a definitive source, it states nicely that "A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time." It also provides some good references for those who would like a more definitive source of information.

Managing By Metrics

2009-04-03T20:25:00.007-06:00

People who work with me are probably getting sick of hearing my rant on managing by metrics. In a nutshell, I find that technical leaders have a tendency to be anti-social (a trait typical, if not slightly less damaging, in their previous career as developers). The path of least resistance for these anti-social managers¹ is to institute rules to take place of communication². Rather than pairing with a developer for an hour or floating from project to project to get a grasp on capabilities and direction, the antisocial manager prefers metrics dealing with code coverage, defect rates and test failure rates.

I only bring this up now, because I heard an interesting story on NPR that I thought paralleled my problems with managing by metrics. All Things Considered compares the struggles the NBA has had with player pay incentives with those on Wall Street. In both cases, employees were given bonuses for reaching individual goals. In both cases, those individual achievements can have a negative impact on the team as a whole. The individual is encouraged to act in the best interest of themselves over the short term to the determent to the larger organization. In essence, people are making bad decisions, because we pay them extra if they do.

Then later, they wonder why
a) the star of the team breaks a scoring record, but the team doesn't make the playoffs
b) the project has great code coverage, but very fragile code
c) your company did so bad it helped drive the entire economy into the crapper, yet your employees somehow earned $270 million in bonuses.

¹ the phrase anti-social manager should be an oxymoron
² Ironically, this is the exact opposite of the first statement in the Agile Manifesto: Individuals and interactions over processes and tools

2009-02-05T20:17:00.004-06:00

Whenever I start learning about a new language on the JVM, I always find myself wanting to sprinkle the new language into my Java code. I never want to be the guy asking to scrap our project and start over in Groovy or Scala. I'd rather just drop down to Groovy to parse some XML, or write a quick Unit Test for my Java code with Scala.

The problem I run into, is that adding code from another language always either involves altering the build process to compile the other language, or adding lots of boilerplate code to interpret an external script. I really don't like either solution.

I think if Sun is going to push multiple languages on the JVM, the first thing they should work on is natural integration with those language from Java.

One solution that would be interesting is similar to GWT's JSNI. In JSNI, you include your Javascript as a comment on a native method. Rather than linking to a native library, the GWT compiler digs the javascript out and includes it in the generated Javascript. Calling code can consider it to be just another Java method:

public static native void alert(String msg) /*-{
$wnd.alert(msg);
}-*/;

I'm not really fond of putting the code in comments. I think that part is just a work around so Google could add the feature without breaking compatibility with IDEs and tools. Something like this might be a little cleaner:

@script(language="javascript")
public static void alert(String msg) {
$wnd.alert(msg);
}

This would be a language change to Java, of course... but I think it would be worth any extra effort. It would allow developers to use the best tool for the job at a much more granular level.

The Java compiler could just shovel the contents of the method into a JSR223 eval block without much thought. In time, other compilers, such as Scala's could be aware of this syntax and could compile the code.

There are other ways to provide support for integrating languages cleanly. Here's a great presentation on C# 4 and how its support for dynamic types will help it integrate with other languages (here's an ipod version for those who don't want to mess with Silverlight). I would never expect Java to move forward this aggressively, so I won't bother go into the details. But it's a good presentation for those who like to daydream.

Video Browsing by direct manipulation

2009-01-24T14:11:00.002-06:00

This is just cool.

and the explanation:

Dogma in Programming

2008-10-13T18:04:00.006-06:00

One of the more harmful trends the programming industry is the tendency of programmers to create dogma to define good programming. I believe there is a basic laziness in people encouraging us to boil down a chapter of thought provoking rational into a bumper sticker or a tag line: "Goto Considered Harmful". In addition to laziness, I think this trend is enforced by a system that ensures that most programmers start with a solid foundation in math, science or engineering - fields of study with provable right and wrong answers to just about everything. I think this conflict leaves a lot of developers in limbo, unable to make forward progress because they will never accept programming as a craft.

Good resources for programmers are everywhere. Books like Effective Java, The Pragmatic Programmer and Clean Code seem like an echo chamber of good programming practices. With the growing popularity of Agile methodologies and test driven development, there is no shortage of resources on how to write good code... from the concept to delivery. But no matter how careful an author is when writing their advice, it will always be taken out of context. I suspect that is the case more in our industry than most due to the relative immaturity of our craft.

Everyone knows a programmer who quotes books, and doesn't understand the meaning behind them. Someone who insists on consistency at the cost of maintainability (hmmm.. why did I want consistency again?). Someone who quotes 'You aren't going to need it' back to a customer advocate who is asking for a new feature. Sometimes context is everything. Sometimes concepts are more important than rules.

Another common type of programmer I've seen a lot will read a great book like Agile Principles and try to turn its practices into laws. Once they identify two seeming conflicting 'laws' or find a rule that conflicts with the reality of their workplace, they stop in their tracks... unable to move forward. "This stuff doesn't work! It doesn't deal with this situation!" Of course all the principles still stand and would apply with a little flexibility, but doing so would require admitting that programmers are more craftsmen than engineers.

Obviously the entire industry doesn't work this way, and the abilities of the typical developer vary greatly between regions, industries and even employers. From time to time, I catch even catch myself over-generalizing things¹. At those times I like to recite my rule: "Dogma in programming is always bad".²

¹ Several times, just while writing this
² Yes, it's meant to be ironic. Its a play on one of my favorite quotes: "All extremists should be shot"

Agile and Geomery

2008-09-17T20:32:00.001-06:00

In geometry we have the pathogen theorem: if you know the length of any two sides of a triangle, then the third is fixed. I think this makes a great metaphor for the primary advantage of using Agile:

Software projects have three variables as well: resources, time and features. If you know two, you can no longer negotiate the third. Resources are almost always fixed, which leaves two variables. Agile forces you to choose a fixed timeline and encourages you to let the features reveal themselves. Waterfall assumes resources and features are fixed, and leaves the deadline for you to discover as the project marches on.

Springy

2008-04-24T18:43:00.004-06:00

How long do you need to work with Spring Webflow before it clicks and you wonder how you ever lived without it?

I only ask because I desperately look forward to that day. Today I'm still doing repetitive text searches through a half-dozen xml files to find out what happens when the user presses the OK button.

Parleys Flex Client

2008-01-17T21:33:00.000-06:00

I consume a lot of technical media, and one of my favorite sources is Parleys.com. They provide recorded presentations from Javapolis, SpringOne and other shows. They recently rolled out a beta Flex version of their site and a companion Air desktop app. It's a very cool application, offering a lot of long awaited features including local downloading of video and full screen viewing.

Parleys is making this release just as I'm pushing out the first milestone of a small flex app at work. I may post a little about Flex after I've had a little time to absorb it. Right now, I'm well within the honeymoon period, and don't think I can give a real balanced viewpoint.

Lines Of Code

2008-01-16T07:44:00.000-06:00

There is a reoccurring misconception that I've seen at several job sites now. Developers seem to be proud of their API, Framework or Library because of how few lines of code the user needs to write, without concern for how many concepts a user must understand. A well written Library will expose as little of its implementation as possible. It will provide a single mental model for the user and a consistent way of interacting with it. While generally, this results in less repeated code, the success of the library cannot be judged on a strict line count.

Too many times, I've seen internals of a library exposed for the sake of removing a 2-3 lines of code from the caller (usually a simple if or for loop). The result is often obviously messy APIs, and a lot of learning on the user's part. It seems that when developing APIs for use internal to their company, developers simply don't have much regard for usability.

Microsoft Volta

2008-01-14T19:40:00.000-06:00

I first heard about Volta on the Java Posse (#154). It was carelessly referred to as a GWT rip-off. Being a long-time listener (and fan) of the Java Posse, I was well aware that opinions expressed about Microsoft products are seldom well researched. I did a little more reading and was interested in what I found.

While Volta does generate Javascript, it does so in a slightly different way than GWT. While GWT reads Java code and compiles to Javascript, Volta reads bytecode (.NET IL) and compiles to Javascript. And while GWT defines its own UI APIs, Volta uses the existing .Net APIs. This means, you can write an app in C# or VB using the form designer, add some annotations to tell the system which parts are client code, and compile the same source to both a thick client and a web app.

Of course, while I can't attest to how well it works (like those at the Java Posse, I don't own a Windows PC), I do think it give us some interesting things to think about in the Java community.

If GWT read bytecode rather than source code, it could support Groovy as well. For those who haven't tried, Groovy builders are a very clean way to write Swing code. They could have been helpful for GWT as well.
Could a single set of UI APIs apply for Applets, Applications and GWT-like Web apps, like Microsoft's Avalon APIs span Silverlight, Windows Apps and Volta UIs?
How many interesting ideas do we miss because we don't watch developments in competing environments?

Applets Still Suck

2007-12-13T16:11:00.000-06:00

Despite all the effort Sun announced at the last Java One, applets still suck. They have for years, so why would it matter? Because JavaFX Script, Sun's latest whiz-bang technology still needs a container to run in. Embed one in a web page, and they still have all the disadvantages of an Applet.

Recently, I've worked on a web project that took advantage of both Applets and Flash technology. The difference in user experience is clear. And despite a complete rewrite of the Java plugin in Java6 Update 10, Sun is still a day late and a dollar short.

First the good news: Sun's version detection scripts work fairly well. The rewrite of the plugin for Firefox was sorely needed and will make a dramatic difference. And although I haven't seen the results, I suspect the modular nature of the new JRE will make for a much lighter weight experience for users.

So what's still missing?

The Applet framework has not been altered in any way. An Applet is still heavy-weight. It still makes an OS call to draw its window. This means that applets (and by extension JavaFX scripts) embedded in your web site will not play nice with CSS Z-orders. You cannot open a CSS dialog or popup on the same page as your applet, as your applet will always be on top.

Although the new plugin will be available as part of Java 6 (beginning with Update 10), it will need to be manually enabled by the user from the control panel. I assume this is because Sun doesn't want to ship new features in an update, which seems reasonable. But because of this, it won't be safe to assume your users can view your applet in a reliable way until Java 7 is widely available. Of course the new plugin won't work in Firefox 2 anyway. It requires Firefox 3. Oh, and it doesn't support Safari. If you run Safari, your at the mercy of Apple. Lets hope none of those JavaFx libraries get compiled to Java 6, because Apple doesn't seem to have plans to support my Powerbook with Java 6... ever.

What about the current plugin? Using the existing plugin can cause unpredictable results. In Firefox, resizing the applet can cause your applet to re-initialize (not just fire events, or call start() again). I've also seen the plugin randomly ignore the page layout and get stuck in an odd place on the screen. Refreshing the page usually fixes the problem, but that isn't something I really want to tell my end user to do. And of course the current plugin has none of the performance improvements made to the new plugin.

With all the excitement over JavaFx lately, I thought it might be a good time to remind people that there isn't a JavaFx plugin. JavaFx in the browser will still suck for all the same reasons Applets do. I expect them to continue to suck, as I see no evidence from Sun that they plan to follow through and actually fix any of this.

JLINQ - Lame

2007-08-23T19:39:00.000-06:00

Wow.

IBM has outdone themselves. I'm struggling to find words to express what I think of their latest announcement. IBM has released a new Eclipse plugin that they call JLinq. It's essentially an O/R mapping tool that does most of its work using design time code generation. It generates SQL from beans or beans from SQL. It's essentially a bunch of Eclipse wizards that generate code. Not especially impressive, and a surprising direction after all the recent hype about JPA, Hibernate and EJB 3.

Of course bad software being released from IBM is nothing new. What I find truly exasperating about JLinq is the name. Surly a Java technology named JLinq would have some resemlence to Microsoft's LINQ technology. It's not only the same acronym, but it stands for the same thing in both technologies: "Language Integrated Query". But while Microsoft's LINQ, is a query language integrated into the programming language (go figure), IBM's LINQ is a code generator integrated into an IDE. WTF?

These kinds of projects are not just an embarrassment to IBM, but might be harmful to the Java community as well. Too many Java developers are completly ignorant of advancements outside thier own community. This kind of confusion isn't helpful. How many developers are going to assume this is a Java port of LINQ, and judge LINQ on the merits of IBM's 3rd rate Eclipse plugin?

LINQ ScreenCast

2007-07-07T11:30:00.000-06:00

The Screening Room has a great screencast on LINQ. It's a little early to get too excited about LINQ, but the demos are very impressive. The combination of declarative type-safe queries and object oriented code makes many of our hot new trendy languages and language features seem like dirty hacks. Specifically many of the new Java features and JSRs take advantage of EL or queries embedded in Strings to get the job done -- effectively dropping down into a dynamic language. While dynamic languages may be the most pragmatic solution today, its nice to see someone is working on a more practical permanent solution.

On a related note, O'Reilly has a good shortcuts book on the under-pinnings of LINQ (LINQ: The Future of Data Access in C# 3.0). My interest in it wasn't about learning about LINQ itself, but what language features had to be added to support it. It does a good job of showing how ambitious this project is.

Bob on Design

2007-06-30T22:22:00.000-06:00

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'.

Hand Coded

2007-06-19T20:24:00.001-06:00

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.

New Lens

2007-05-20T21:40:00.001-06:00

Last week I got a macro lens I've been looking at for quite a while (Canon EF 100mm f/2.8). I have mixed feelings about it so far. It does its job very well, but I'm a little frustrated at how completely useless it is outside of macro photography. With my other lenses, I can work a little outside their area of expertise when a good shot presents itself, but because this lens is fixed at 100mm, using it for a casual photo in a pinch is a bit of a pain. That aside, I really love what it does with macro photos. It gives me a decent working distance from the subject and the short focal distance, while a little difficult to work with, can really make a photo stand out.

The detail in the Frog's eye is great (check out the full size version on flickr). What you can't really see from this picture, is that the entire frog is about the size of my thumbnail.

I cropped this one a little. Keeping the ant's head in focus was a bit tricky with a monopod. I may need to start using my tripod a bit more often.

Distributed Version Control

2007-05-17T21:27:00.000-06:00

Linus gave a presentation on git, his distributed version control system. I've heard a lot about git and bitkeeper, but hadn't paid much attention until this presentation. If you haven't taken the time to learn about distributed version control, you should take an hour tonight and watch the presentation.

Thanks to Kyle Cordes for posting the link on the JUG mailing list.

Building the IDEA Groovy Plugin

2007-05-12T21:19:00.000-06:00

It took me a little effort to get Idea's Groovy Plugin built, so I thought I'd share my experiences for those who don't want to fall in the same traps.

I started from some instructions on the forums, but still had trouble. Some filenames were wrong, and working on the mac changed some of the details. Here are my revised instructions:

Update to a new EAP of IDEA. The plugin wasn't built for IDEA 6
Checkout the project from http://svn.jetbrains.org/idea/Trunk/groovy/
When you first open the project, you may be asked to make a variable association. I pointed the templates variable to ${project}/resources/fileTemplates
I had to create a new Intellij IDEA SDK pointing it to my IDEA installation
Add tools.jar (on windows) or classes.jar (on the mac) from your JDK installation to the SDK classpath
Add idea.jar from your idea installation (on the mac, the file is /Applications/Selena-6951.app/lib/idea.jar) to your SDK classpath
There are already two ant scripts in the ant window. Run the one called generate lexer from groovy
Run the build>make command from IDEA's menu
Run the build>Prepare Plugin Module 'groovy' for deployment command from IDEA's menu
A zip file will be generated to the project directory. Copy it to IDEA's plugin directory and unzip it.
Restart IDEA

I've attached the file for those daring enough to install software from some stranger's blog: groovy.zip

JavaFX in Perspective

2007-05-09T21:47:00.000-06:00

The large number of discussion about JavaFX over the last few days seems be very polarized. So far I have only read two opinions repeated over and over:

JavaFX is the competitor to Flash and SilverLight that we've all been waiting for.
JavaFX is a weak attempt to cash in on the recent SilverLight announcements and has no chance for success.

What most people don't seem to get, is that JavaFX isn't even in the same market as Flash and SilverLight. It's much more appropriate to compare JavaFX with XAML or Flex (just the markup language, not the action script, runtime environment, multimedia support or animation).

Both Adobe's product line and Microsofts are made up of several packages:

A runtime environment - The Flash VM and the .Net Runtime
A declarative UI language including widgets - Flex and a light version of XAML
A declarative animation language - Flash and XAML
A scripting language for procedural logic - Action Script and JavaScript
A development environment for each of these three languages
Multimedia components - video and audio playback is supported well as first class components in both frameworks

Of course JavaFX runs on the Java runtime environment, and it defines a very nice language for declarative UI building and a decent language for animation... but that's all it tries to do.

Sun has yet to show any interest in completing the rest of the picture.

It could be argued that some work would need to be done to the JRE before it could be light enough to compete with Flash or Silverlight as a runtime environment (at least ease of installation could use some work).
JavaFX has no equivalent to JavaScript. Although one could theoretically use Java, Groovy, Javascript or some other language for procedural code, the binding isn't nearly as nice as the integration the other two frameworks have with their scripting languages.
Netbeans provides some syntax highlighting and code completion for the language, but it's barely better than notepad when compared to the authoring tools being offered by Adobe. To take on the competition, Netbeans will need timeline driven animation and Matise-like component layout from day one. On day two, we need vector drawing tools to compete with Illustrator and Expression (tie-in with existing tools might be a nice stop gap).
Multimedia support has always been a weakness in Java. JavaFX is the neon sign pointing out one of Sun's often ignored weakesses.

With all that said, JavaFX compares very nicely to Flex and XAML when ignoring their sister technologies. Feature for feature it compares nicely. Without the rest of the package, of course, it's all pretty academic. Assuming Sun is really serious about taking on Adobe and Microsoft, they still have a lot of work ahead of them.

WPF & Flex

2007-03-19T20:35:00.000-06:00

I went to a .Net User's Group meeting about WPF tonight. The speaker was Walt Ritscher. The presentation was a pretty decent intro. I was expecting it to be quite a bit more in depth. I guess I figured .Net developers would already be up to speed on WPF and an intro presentation would be beyond them at this point. I seem to make a habit of setting my expectations a little too high for most user group presentations.

I recently signed up for a membership at lynda.com, which provides instructional videos on many technical topics. The subject matter tends to lean towards creative tools (Photoshop). I've been watching the Flex training videos and I can't help notice the similarities to what Microsoft is doing with WPF. Macromedia really seemed to have missed the boat by brining application development to Flash so late in the game, but they seem to be catching up well now that Microsoft has put some fear into them. Since Adobe took over, they've kept going strong.

Of course both Flex and WPF/E are both proprietary technologies that have fairly useless free SDKs and $600 development environments for the serious user. I haven't seen any free alternatives with anything close to the capabilities. Both SVG and F3 have similar capabilities, but F3 isn't open and lacks the development tools and SVG lacks good browser support.

Oh well... guess we'll have to put up with Ajax for a few more years.

IntelliLang

2007-03-14T23:50:00.000-06:00

IntilliLang is a very cool plugin for Idea that (among other things) allows stringified code to be parsed as any other code. This means those regular expressions and html fragments you store as a Java String can be parsed, checked and auto-completed as a first-class citizen.

Jetbrains shows some very cool examples including regular expressions, javascript and el. It still has some rough edges, but once its cleaned up a bit, it could be a great tool for HQL queries and embedded SQL.

Lightroom

2007-02-25T23:30:00.000-06:00

I had been using the beta of Lightroom since its first release. Initially I wanted to use it rather than Apature because of Apature's lack of good Photoshop integration. Ironically, Lightroom didn't play well with Photoshop either. My biggest complaint was that Bridge and Camera Raw didn't recognize edits made from Lightroom. Although this is fixed in Lightroom 1.0, at the time I had to work in either Bridge/Camera Raw/Photoshop or Lightroom/Photoshop.

I like the Bridge/Camera Raw workflow because it's filesystem based. I don't like applications managing my files. But Camera Raw, as powerful as it is, is a clunky tack-on dialog where I really want an emersive tool. When I'm editing my photos, I work on them for hours at a time. I don't want to jump around between dialogs and have to save copies of my files.

After a couple months, I gave up completly on Bridge/Camera Raw. I was soon using Lightroom for all my post-processing, and doing touchups in Photoshop. As sad as it might be, I was using Photoshop solely for removing zits and cleaning up tape marks on my son's face (because of medical issues, he uses oxygen at night. His cannula has to be taped to his face). $600 of image processing power, devoted to removing tape and pimples.

And then Lightroom 1.0 was released. One of it's new features: Spot Removal. Here's the twist. Rather than saving a copy of the RAW file to edit in Photoshop, Lightroom's edits are lossless changes to the RAW file. While the Photoshop tool is more like a raster based brush, in Lightroom all the corrections are circles with source and destination references. Those references can be altered or cleared at any time in the future.

In the example above, I've made several corrections. The active one is represented by the two circles at either end of the arrow. The arrow is saying "copy everything in this circle to this one". At first it seemed rather limiting to have to use circles rather than a brush, but after a little time, I've found it to be very powerful.

What's more, this single tool has completely eliminated Photoshop from my regular workflow. While I still use Photoshop from time to time for other projects, I don't really need it for photo processing any more.

Thoughts On Music

2007-02-07T19:10:00.000-06:00

For those who haven't read it, Steve Job's article denouncing DRM is a good read. I was expecting typical corporate finger pointing related to the problems Apple is having in Europe, but Jobs makes some very good points. He also points out a pretty decent explanation to why the Zune doesn't use playsforsure DRM.

Swing and Vendor Lock-in

2007-02-06T07:03:00.000-06:00

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.