An Interview with Tim Boudreau, Part I

A day before JavaOne 2006, Bill Venners and I queued up for admission to NetBeans Day, a one-day developer conference for users of Sun's open-source IDE. The long line and standing-room only presentations motivated us to dive a bit deeper into the recent resurgence of both the tool and the developer community formed around it. In a subsequent interview with NetBeans evangelist Tim Boudreau, we asked about some unique upcoming NetBeans features, and about Sun's vision for NetBeans.

Tim Boudreau: The NetBeans 5.5 release is all about taking a lot of pain out of Java EE 5 development. We added support for EJB 3, and you can use annotations in many places to specify, for example, business methods.

The NetBeans Enterprise Pack, which is also freely available, provides many additional features that were initially in Java Studio Enterprise. Java Studio Enterprise was Sun's commercial offering, bundling NetBeans with additional modules. We released that open-source as well, as part of our strategy of providing a more integrated developer experience, rather than having different IDEs.

The Enterprise Pack offers XML support on steroids, allowing you to refactor your XML, in addition to schema support and basic XML editing. UML support is another of important Enterprise Pack feature. And if you have a bunch of Web services and you need to make them all talk to each other, you can use NetBean's BPEL support to orchestrate that.

Frank Sommers: NetBeans 6.0 is already in its second milestone release. What new 6.0 features are you most excited about?

Tim Boudreau: In 6.0, we're migrating to a new API for parsing a Java syntax tree. That is based on the new Java Compiler API spec [JSR 199], which is a canonical API for interacting with the Java compiler and with the data the compiler produces. It gives you access to the guts of the [Java] compiler, and especially to what the compiler's parser does. That allows us to integrate javac directly into the IDE. It sits underneath the editor, and makes possible many new editor features. One thing you can do, for example, is to compile code on the fly as you type. Using the parser from the Java compiler also gives you really accurate information about the code, and allows you to build code refactoring tools that are more powerful than what's available in other tools today.

Speaking of refactoring, you may have heard of the Jackpot project that defines a pattern language for matching in a Java syntax tree and then, more important, for doing transformations on that tree. Jackpot came out of SunLabs, and is now available in development builds of NetBeans.

The implications of these tools are pretty profound, because they change the meaning of how you deal with backwards compatibility, and how much of an issue backwards compatibility is. Suppose that I'm maintaining a library, and need to make some backward-incompatible change. I paint myself into a corner where I can't fix a bug without breaking some part of the API, for instance, by making something that was legal, illegal in the new version. Nobody designs their APIs perfectly from the get-go, so those situations happen.

With these tools, I can write a simple transform that anybody using this library can run against their code, and that transformer will update their code to the new version. I'm not talking about a shell script, but something built around stuff that's in Java source files, something that does that update correctly, and is pretty fool-proof. For instance, we are shipping a rule that converts StringBufferusages to StringBuilder, and another one that updates StringTokenizer to Scanner.

Jackpot has the potential to do rather large refactorings correctly, and it actually brings down the cost of writing transformations or refactorings rather, makes those refactorings reasonable even in esoteric situations. Just the other day, I was contemplating how to refactor existing Swing code that uses ActionListeners on UI controls to turn all those ActionListeners into Action objects, move the right code to the right places, and end up with something better factored, easy to understand, and compilable. That sort of thing nobody would have attempted prior to Jackpot—it would have just been too ambitious and too hard to get right for the amount of value such a tool would bring.

There are still cases where subtleties and mismatches prevent you from automatical update. For ninety-nine percent of the cases, you can write a transformer that removes the upgrade pain. And the transformer can flag even that remaining one percent. Sometimes the replacement for something that was deprecated or removed before may not have a direct equivalent for a method, if that method was rarely used. For that situation, deciding the right thing is up to the user. For all those transformations, you can see a preview and diff for every change that is to be made. So it's not just refactoring, it's code re-engineering.

Almost every piece of software is an evolving beast. Being able to integrate these transforms, and actually have upgrading not be painful in the long-term, is going to make a big difference in the way people code and in how people design.

Frank Sommers: You said the strategy for NetBeans is to have one IDE, and have various plug-ins that extend the IDE's functionality. That sounds very similar to what the Eclipse community is doing. Going forward, what do you see as the key differentiator between NetBeans and Eclipse?

Tim Boudreau: A key part of building an ecosystem is that you have to choose some places to fail in, and ideally to fail spectacularly so as to create niches for the participants to thrive. At the moment, with Eclipse that area is quality.

At an EclipseCon presentation I attended, a presenter from a large technology company explained that they have their own QA group to test different combinations of Eclipse plug-ins to help decide which ones actually work together. Those will then be the ones their developers shall thereafter use. That's pretty bizarre, because it's like having your own QA department to test MS Word or your operating system.

To their credit, it's clear they know there's a problem. But while there's some pressure from NetBeans and elsewhere to get their [Eclipse's] act together in the "batteries-included" area, we also see pressure from the vendors occupying that niche advocating that they [Eclipse] not get their act together, as it would be a direct threat to those vendors' business. The perversities you build into such a system get pretty entrenched.

We talked with some of the folks doing Eclipse distros to create alternate NetBeans distros, and the feedback we got is that they don't see where they could add enough value. They find that what you get from netbeans.org is already tested, works, and is well integrated, and the general quality of the available plug-ins is high. There is no DLL-hell situation with NetBeans, the pieces are heavily QA'd and tested.

We're doing some interesting things in the partner program department, but I don't think we want to have the same problems the Eclipse folks are having. There are a set of choices when it comes to an ecosystem, and the worst thing we could possibly do is to "choose" to fail in exactly the same ways. That's not a recipe for success. Long term, I'd expect Eclipse to be to this generation of developers what vi was to an earlier generation. It's certainly not going to go away any more than NetBeans will. It's really about longevity: If you want to make a big PR bang, lining up oodles of partners is a good way to do that. I'm more interested in what happens after the big bang, what developer experience is going to be like in your tool five or ten years down the road.

In Part II...

Tim Boudreau will talk about how the Matisse UI builder addresses cross-platform UI development, the relationship between the NetBeans rich-client platform and JSR 296, Swing Application Framework, as well as about NetBeans' future language support.

Resources

NetBeans home page:
http://www.netbeans.org

JSR 199, Java Compiler API
http://www.jcp.org/en/jsr/detail?id=199

Talk back!

Have an opinion? Readers have already posted 2 comments about this article. Why not add yours?

About the author

Frank Sommers is an Artima senior editor.