In the second installment of his interview with Artima, NetBeans
evangelist Tim Boudreau talks about the NetBeans rich-client platform,
how the NetBeans Matisse UI builder and GroupLayout layout manager
address the challenges of cross-platform and internationalized UI
design, and about support for languages other than Java in NetBeans.

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 for objects to become
mainstream.