An Interview with Tim Boudreau, Part 2

Following the NetBeans project's release of the 5.5 beta of its open-source IDE, Artima spoke with NetBeans evangelist Tim Boudreau about NetBeans 5.5, as well as future directions of the IDE. In the concluding segment of this interview, Boudreau talks about the NetBeans platform, GroupLayout, the Matisse GUI builder, and NetBeans' support for languages other than Java.

Frank Sommers: At JavaOne 2006, you demonstrated Matisse, the NetBeans 5.5 graphical user-interface editor, and said that Matisse is really a different kind of UI editor from anything that came before it. What makes Matisse so unique?

Tim Boudreau: Java UIs are interesting because of the requirement to work well on multiple platforms. There are user interface design guidelines for every platform. Apple has them for the Mac, Microsoft has them for Windows, and there is the Java Look And Feel Guidelines. UI standards are a great thing, because they make things look familiar to users. At the same time, everyone has a slightly different take on what looks right on a platform, such as how far from the edge of a window you should put a label, for instance.

We attempted to abstract all that complexity out into a new layout manager, GroupLayout. GroupLayout is being developed as a project on java.net, and it will be a core part of Swing in JDK 6. GroupLayout lets you specify that certain components on a form have some kind of a relationship to each other, such as a positioning relationship or an alignment relationship.

For instance, consider aligning two components. Taken individually, a JLabel with some text is of a different height than a JButton with text is. But if you put the JButton and the label next to each other, you want them to share a common baseline, because it's provable that people read faster and are able to understand it if the eye can follow a straight line. GroupLayout makes that really easy.

Contrast that with other layout managers that require that all of the components be on a grid, with one component occupying two cells, and another one occupying one. Among other things, GroupLayout handles spacing very nicely, always taking into account the platform you execute the software on.

Matisse does its work by interacting with GroupLayout. When you're designing your UI, Matisse will give you guidelines on using the recommended positioning for whatever platform you're designing on. It will snap components in place for you. But when you move the application to a different platform, the layout manager is going to use the spacing that that platform's design guidelines recommend, and Swing will use the correct borders and font. It solves at a deep level the Java-app-as-alien myth, and makes it easy to develop things that look right everywhere.

Localization is another issue you have to consider when designing a UI. Depending on what kind of software you're writing, localization is either very important to you, or not important at all. There is not much middle ground. If you go to places like India, for instance, with all sorts of languages spoken there, localization is hugely important.

In the Windows world, you edit a resource file, and then compile that with a resource compiler. Java gives you a more dynamic option with a property resource bundle implementation that's separated from the mainline application code. The resource bundle provides strings to the application that are plugged into the UI. While that gives you more flexibility, it also puts a lot more pressure on the layout manager. The layout manager has to handle, for example, extremely long words you might have in German as well as some other languages where you might have very short words for the same thing.

Matisse really helps you with localization, because it makes localization transparent. When you double-click a component and type some text, the text is written to a properties file, and the correct code is generated to obtain values from internationalized versions of that properties file. NetBeans also has a feature that allows you to go through your source code and convert all the hard-coded strings to localized variables. Many people have been using NetBeans just for those localization features. And that works not just for Swing applications, but for any app that wants to use resource bundles, which is the standard way of doing localization in Java.

Frank Sommers: Another demo you did at JavaOne was to quickly build a desktop application with the NetBeans rich-client framework, or NetBeans RCP. What is NetBeans RCP, and how does it relate to the Swing Application Framework JSR [JSR 296]?

Tim Boudreau: There are many problems you need to solve when building a desktop application. You would use the NetBeans platform for pretty large applications, something fairly complex. For applications that are at a lower level of complexity, there are some basic problems that would be nice to solve in the Java platform. For example, how do you store defaults that are localizable? Or, how do you provide generic access to resources which might be colors or fonts? These problems are a bit more low-level than the ones the NetBeans Platform tries to solve, though NetBeans RCP must handle them as well. JSR 296 is aimed at very low-level application plumbing, like the examples I just mentioned, or at simplifying writing Actions, and that sort of thing. These efforts are complementary.

The NetBeans RCP tries to solve the application architecture problem. When you get to a certain size application, the NetBeans platform could make things a lot easier. If you're writing a desktop application, there is a certain amount of plumbing you just have to deal with that a raw UI toolkit, such as Swing, doesn't address. You will have menus, keyboard shortcuts, actions, and you will need to have some kind of window management if you want to show multiple components. You're going to want to save settings on shutdown, and restore the whole or a partial state of the application when you restart. Data access gets kind of interesting as well.

The [NetBeans] platform handles that plumbing. For example, if you're accessing resources in NetBeans [RCP], you can use the Filesystems API to interact with local files, resources inside JARs, on an FTP server, or on some remote server, as if those were local files. As well, NetBeans [RCP] has a "generic hierarchy and presentation" library—the Nodes API. You have nodes, and each node can have children objects. A node is the presentation layer—nodes have actions, display names, icons, etc.i—all of the basics for presenting most any data model to the user. Put the Filesystems and Nodes pieces together, and you have something very powerful—a lot of complex UIs for which you'd use a tree or a list control, you can do very simply in NetBeans [RCP] just by sticking a file in a virtual folder, and opening a view of that folder. The Explorer API provides a wealth of Swing components which can present a Node and its children in a variety of ways.

Finally, the modules system in NetBeans [RCP] is about how you design an application that's maintainable. Modules allow you to factor an application into different pieces, with classes that are not public outside their own JAR. A module can declare what packages other modules are allowed to call classes from; classes in other packages are public only within the JAR they live in. There will probably be something along those lines as a language feature in Java 7, but the NetBeans RCP already provides that for desktop applications.

Frank Sommers: At the moment, NetBeans is mainly a Java IDE, but it also supports C and C++. What other languages do you envision NetBeans supporting? Do you see NetBeans becoming a language-agnostic IDE platform in the same way Eclipse aims to be?

Tim Boudreau: NetBeans hasn't been just about Java since sometime around 1998. It's been the foundation of the C/C++ tools Sun has been shipping for Solaris for many years; that support is being broadened and generalized now into something that's not Solaris-specific. NetBeans is also the IDE that HP ships for OpenVMS, supporting COBOL, Fortran, C/C++, and several other languages[1].

There are some interesting efforts happening now, such as the support for VB that we demoed at JavaOne this year—actually taking VB code and compiling it down to Java bytecode and having it run, sometimes faster than the native code it would originally have been compiled down to. So, we've got that project happening, and also a bunch of other efforts around scripting languages. NetBeans isn't tied specifically to being a Java IDE in any way—it just happens that there is great support for Java already, so that's the first thing people think of. To answer your question, NetBeans already is a language-agnostic platform.

As I mentioned earlier, the important thing is longevity. Some people claim that Java will be dead in five or ten years, and we'll all be on to the Next Big Thing. Even if that were so, NetBeans would probably be supporting that Next Big Thing. But there's an important thing to consider when making assumptions about the longevity of languages. It's realistic to expect the cycle of the reign of any particular language or paradigm in programming to become progressively longer over time, for two reasons. First, because we are getting better at mapping how people think to the way we tell a computer to do things. And, second, because the longer any one language is the dominant one, the more code there is in that language, and therefore the greater the cost of migration. So you have to come up with something really compelling to make changing languages interesting.

There is much talk about scripting language now, but I'd expect the next major shift in mainstream programming languages to be something that makes parallelism intuitive as multi-core chips are becoming the norm. Java has excellent support for multi-threading, but it still forces you to think about multi-threading aspects of your code. There are languages like Clean[2] that provide transparent multi-threading—you take all your context with you. But they're still far from intuitive, and some things still require context. How would you write a GUI toolkit in a language where everything, in effect, is an argument? I'm sure there are ways, but making it easy and intuitive is hard. It's something that will take a while. Just consider how long it took

Resources

[1] HP's NetBeans-based OpenVMS IDE
http://h71000.www7.hp.com/openvms/products/ips/netbeans

[2] The Clean Language
http://www.cs.ru.nl/~clean/

Other Resources:

JSR 296, Swing Application Framework
http://www.jcp.org/en/jsr/detail?id=296

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

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.