I prefer not to write GUIs. GUI programming can be fun in its own right, but GUI libraries tend to be particularly “quirky”. I don’t like learning a style that can sometimes be very arbitrary. Also, “everyone’s an expert” when it comes to evaluating a GUI, which can be frustrating at times.
So when I needed to write a small tool to assist with testing, I thought to use NetBeans and its “Project Matisse” GUI builder to avoid forgotten Swing APIs.
From a GUI perspective, the application called for some simple text fields, lists, and buttons. Nothing fancy at all, perhaps a half-dozen widgets, discounting panels and labels.
Having completed the application (a day or two’s work), I conclude that NetBeans as an IDE isn’t a replacement for Eclipse. The advantage of Eclipse’s rich plugin community and general first-mover advantage aside, NetBeans is deficient in a at least a few ways that are readily apparent. I offer the caveat that it’s possible I simply don’t know my way around NetBeans, rather than it being that NetBeans is deficient.
The auto-completion is case sensitive. This is seemingly minor, but frustrating. For instance, typing in setv yields no results, but typing in setV shows setValue(). I usually type around 90%+ accuracy, but coming from the less picky Eclipse makes NetBeans’ behaviour unpleasant.
I couldn’t find an equivalent to Eclipse’s Quickfix ability (Ctrl+1). While NetBeans could correct missing imports as part of its Organize Imports ability, uncaught exceptions had to be manually addressed, rather than being able to auto-generate a skeleton try-catch block.
In order to add a library dependency to the project, I had to define the library and point to its binaries (and optional Javadocs). That part is fine, but NetBeans would store the path reference absolutely rather than relative to the project root. That works for a single developer on a single machine, but for multiple machines accessing a shared code repository, it doesn’t make any sense. The project definition has to be checked in, yet by design it stores information in such a way that makes it unlikely to work on any other machine. I tried editing the XML directly to use relative paths, but that didn’t work.
As a GUI builder, however, NetBeans is pretty good. There’s the typical drag-and-drop of components onto the panel. More notably, as you move and resize the widgets, the builder provide visual hints for alignment with a small dotted line that appears when you reach an “alignment point”.
I don’t know how the NetBeans documentation describes it, but the application will notice that the widget above is left aligned at a certain position, and so will hint when you’re at the same alignment. It also correctly guesses that if you stretch the widget to the edge of the panel, you’re expecting it to resize with the window (e.g maximization).
There are similar visual cues for horizontal alignment.
The GUI builder did sometimes incorrectly guess how the widget should resize with the window. It also occasionally would change the overall widget layout in a drastically incorrect manner if I dragged widgets in certain ways, e.g. tried to move to the far left an existing text field that was “locked in alignment” with some other widgets, and NetBeans shifted all the other widgets far to the right. In all the cases I experienced, however, it was a matter of learning how NetBeans “thinks”, and working with the designer to do operations “in the right order”. The “right order” wasn’t particularly odious to follow.
NetBeans also provided other typical GUI builder functionality, like displaying all the possible event handlers for a widget, property tables, and auto-generating the boilerplate skeleton for the method. However, at this point I started to run into NetBeans’ shortcoming as an IDE again.
Renaming widget instance variables is possible from the designer, but it does not refactor any of the existing uses of that variable name. One essentially has to name the widget correctly the first time it’s brought from the palette.
I also found it a little frustrating I couldn’t remove methods very easily. When flipping from Design to Source mode, it appears that you get a text editing screen. However, certain areas can’t be edited, such as the method signature of event handlers and the instance fields. Unable to remove the method of a handler I was no longer interested in, I left it blank. Unable to add my own instance fields, I didn’t bother reusing HttpConnection instances (it’s a test tool, so that’s okay from a quality perspective).
In the future, I’ll use NetBeans to do quick and dirty GUI applications, but for significant work, I can’t see myself using it. The penalty in the IDE is too great. Perhaps a hybrid approach, where the heavy lifting is done in a library written with Eclipse, and then create the GUI to call the library via NetBeans?
I’d like to try an Eclipse/SWT GUI designer some time to compare, but the main drawback is that Swing is in the core Java runtime, while SWT is not. However, the look of SWT, to compare Eclipse and NetBeans anyway, is much better than Swing; it might be worth the trouble in that respect.
