{nule.org}

A quick note on the beta/release candidates

Since I wrote this article, the beta has evolved to the first release candidate and on to the second and I’ve upgraded to stay current on it. I still use 6.1 as my main IDE after about three weeks of use. CPU utilization is still higher than expected, and higher than I’d like, but it’s not enough to get me to stop using it (rc1 was worse than the beta in this respect, but rc2 seems the best so far). One of the Sun folks is helping me diagnose the issue, so hopefully it’ll be resolved by the time the final release is complete.

There is one new bug I’ve found and reported (at least in rc1, not sure yet about rc2). It seems you can’t import a new project into a CVS repository. I’ve had to work around the by importing from the command-line, then checking the project out within NetBeans, which isn’t too annoying. It does kind of go to show that with a project this complicated, it’s nearly impossible to have everything working perfectly for new release.

Lastly, I’m amending some of the data below because I remembered another longstanding annoyance, which has to do with JUnit tests in Java projects. I have yet to be able to get JUnit tests to work so that I can just click on a “run tests” button and have them go (confirmed, still a problem in rc2). I’m not exactly sure if that’s because this code was imported into NetBeans long ago, but it still seams there should be a way to get the unit tests to work more easily.

Introduction

Over the years my preferences for programming environments have changed dramatically as my preferences for languages themselves. Initially my mantra was basically little more than “there is no language but Perl” and with that there was little reason for any programming editor beyond VIM (and I must profess on ongoing affection for this extremely capable editor). Over time as my projects grew increasingly complex and my need to code efficiently became paramount, Perl no longer fit my development style optimally and I experimented with a bevy of other languages until I settled most development in Java (but this isn’t really a language discussion, I promise). Likewise I outgrew the simple pure-programming editor style of environment in favor of a more advanced integrated development environment (IDE) that could help me manage projects and all aspects of the development cycle.

In the past few years NetBeans has been my IDE of choice, and recent releases have only served to solidify its position as the environment in which I wish to work. I do look around at what else is out there, but I never stray far. The purpose of this article is to take a look at the upcoming release of NetBeans to see if it continues the tradition of enhancements and polish the product has seen in each iteration since the 4.x days. We will take a look at NetBeans 6.1 in general, for those that may not be that familiar with it and its capabilities. We’ll also be looking at what 6.1 offers over previous editions and to see if the handful of nagging glitches introduced in the 6.0 series persist in the latest builds.

Contents

• Caveat
• Overview
• Installation
• First Run
• Java Applications and GUIs
• Application Servers and EE5
• JavaServer Faces and the NPE
• Near Hits
• Itemized Improvements
• Remaining Annoyances
• Conclusion

Caveat (top)

If you’re new to programming in general or even if you’re just a recent convert to Java, you might want to stop reading (or start by looking at my Java Tutorial or any of a number of other worthy sources for learning about programming). I’ve maintained throughout my years of mentoring other programmers that an IDE is not the place to learn to program. Yes it is nice to click on the button that says run without having to worry about classpaths and where your compiler is located, but it’s no way to to learn what’s going on under the hood. Once you have a firm grasp of what the pieces are and what they do, then by all means use an IDE to accelerate your development process. That’s what an IDE is all about, after all, bringing the mechanics of coding closer to the thought-processes behind being a coder.

Overview (top)

If you’re a long time coder you probably have a good idea of what an IDE is, and really what NetBeans (and most other IDEs) provide. It’s more than just syntax highlighting and a simple button to run your code. If an IDE does its job right, it helps you organize your projects, make compiling, debugging (and profiling), revision control and documentation (and more!) easier than maintaining all that by hand.

Installation (well, upgrade, actually) (top)

First, if you are upgrading a previous version of NetBeans and intend to work on code you have lying about, make sure that you’ve checked it all into your revision system! Not that NetBeans is going to corrupt anything, but something unpredictable could happen with any new version of software so it pays to be safe. If you don’t have revision control for your source, first of all you need to be slapped silly, but more importantly, at least zip or tar things up before you proceed.

Second, let me mention that some of this may only apply to a Mac. This install was performed on a new Mac running OS X 10.5, with everything patched up nicely. Previously I had installed NetBeans 6.0, replaced that with 6.0.1, and performed routine upgrades on those installations. When I grab a newly released version of NetBeans I typically get the all-inclusive release (which sadly doesn’t include the UML or Mobility packages in the Mac version) and install all of the pieces. I also should mention that I heavily use JBoss 4.0.5.GA, and that remained untouched during my tests of NetBeans 6.1.

Somewhere around 5.5.1 the installer improved considerably on the Mac. For 6.0 the download was a typical disk image with 4 installers inside that provide the IDE, Glassfish, Tomcat and OpenESB. 6.1 was no different, offering only slightly upgraded versions of some of those secondary products if you’ve previously installed 6.0. As of the release candidates, there is a single package that installs all the components of the download you choose. The installs themselves proceed flawlessly and an easy to follow readme document is included with straight-forward instructions.

First Run (top)

The first time I ran the new version it, like its predecessors, detected that I had earlier versions of NetBeans installed and asked if I wanted to import my settings. Just like prior versions I declined to allow it to do so. My feeling is that over time settings directories accumulate unneeded cruft, and letting it start with the default settings prevents old preferences from potentially introducing errors or strange behaviors into new versions. Granted, it most likely works fine, but I don’t tend to customize too much of any software I use. At any rate, with the default settings this is what the initial screen looks like on a Mac:

If you’re not familiar with a Mac, the normal “file, edit, view, help” menus are at the top of the screen, not on the application window for most applications. Those options exist as you would expect them to, just not pictured here. (As an aside, in 6.1 rc1 the file and other windows where on the application window, even on the mac. This was corrected in rc2 to put the menus back where a mac user would expect them on that platform.)

I have a fairly substantial set of projects I regularly work on (46 of them, to be exact in my ~/NetBeans/ directory), so my next step is to ensure they still open mostly as expected. My first grab was of my HL7 Comm project, which worked just as expected, though as a first project opening it seems the system’s Java classpaths did get scanned and indexed, as well as the projects recompiled. Not terribly time consuming of a process, but it does take a few moments and it’s worth noting that it only happens once. Here’s my projects, just as I left them:

There are four projects that make up HL7 Comm, and you can see them in a collapsed state at the left. The blue icon near the project name means that NetBeans at least thinks that there are uncommitted changes that need to be checked in to your revision control. With prior versions of NetBeans I noticed that this notification tends to be a bit aggressive and it would sometimes think things were out of date when they weren’t. This is easily corrected by updating your project from your repository.

Upon doing so with these projects, as expected it found that none of the actual code had changed, but somewhat predictably, some of the project files had:

M nbproject/build-impl.xml
M nbproject/genfiles.properties


I’m fine with letting NetBeans muck with its project files all it wants, but this is a great reason to make sure you have backups in case you needed to go back to your previous version. In theory you may not be able to open the projects in an older NetBeans once these files are modified, in practice I’ve found you normally can. Still, it’s better to be safe.

I checked the “clean and build” function as well as the “run” function, both of which are among the two most used features of the IDE, and indeed the project built and ran normally. I’ve found that particularly the “clean and build” can fix problems in projects that shouldn’t happen but sometimes do with IDEs, particularly as they may take shortcuts that seem safe but can leave files in an inconsistent state. I didn’t see that with the upgrade to 6.1, but it’s something else worth keeping in mind.

Java Applications and GUIs (top)

One of the things that initially didn’t impress me much in NetBeans but I can now no-longer live without, is the Matisse GUI builder functionality. With stand-alone Java applications (like HL7 Comm and some of the other apps lying about nule.org), it can dramatically speed up creating complex Swing GUIs, particularly forms, and help produce professional looking interfaces. One problem, however, is that upgrades in the past have silently modified Matisse form elements in such a way that they could not be opened in older versions of the GUI builder. (I believe this was in the switch from 5.5 to 6, and I do recall that the documentation warned you of this effect).

This is what the GUI builder looks like in the latest version:

It’s a nearly WYSIWYG editor where you can simply drag and drop Swing components, and even custom built components onto JFrame and JPanel elements and to preview their appearance without having to touch any code. It simplifies adding actions (like a button or list listener) to elements by creating the appropriate methods for you to fill in, and the properties editor makes creating a consistent look easy.

As handy as it is, there have always been problems with the builder throughout versions, though in recent iterations they’ve improved markedly. Functionally I can detect no changes between the 6.1 and 6.0 editors (and that’s good for the most part), but annoying little peculiarities remain. For example, in the screen shot above the largish JTextArea element towards the upper right of the GUI window has been placed at the very edge of the enclosing JPanel (which has a grooved border). Any attempts to drag the lower edge down to the bottom edge of the JPanel result in the JPanel adjusting itself larger to maintain the spacing between the elements. There may, perhaps, be a way around this flaw, but after considerably playing in both 6.0 and 6.1, it eludes me. And it’s not a particularly terrible bug, but it prevents me from being able to achieve precisely the look that I want. It’s especially frustrating because it looks like it’s going to work before it ends up resizing everything, so it’s tempting to try over and over instead of doing productive work, like the actual coding that gives the page its function. Though this bug persists between versions I can live with it, and I was able to confirm that once I played with page some in 6.1 it would still open fine in 6.0.

Application Servers and EE5 (top)

Though I heartily enjoy coding stand-alone applications in Java and Swing (no, really, I think Java is really underestimated as a solid application development platform and NetBeans really demonstrates that fact), most of my paid development time is spent working on Java EE 5 code. Enterprise Java support is really what drove me to NetBeans to begin with. At the time I was using Eclipse for much of my work, but in those days (and possibly still) there was positively no support for working with JSP pages outside of a very basic editor. Apparently JBoss (and others?) had add-ons that helped, but they seemed practically non-functional, and made what was, at least on Linux, an unstable product into an absolute crash-fest.

NetBeans in those days was just graduating to the 4. something series, and made what were my first tentative steps into the Java EE world a lot more palatable. Struggling to understand JSP and Servlets not to mention how to make them interact “the right way” (hint – MVC!), was daunting, and NetBeans provided just enough hand-holding with JSP syntax highlighting, automatic tag completion assistance and tag documentation to let me learn enough to learn the rest on my own. Additionally learning how to package .war and .ear projects including the requisite meta information was (and remains to an extent) not a well documented process, so the automated builds provided by the IDE were hugely helpful.

Jump ahead to the current version and you find the current NetBeans to be light-years ahead of what we had back then. They’ve really made the incredibly complex tasks behind creating and deploying enterprise projects pretty much as easy as they can be. In the next screen capture, you can see I added my custom deployment of JBoss 4.0.5.GA to the list of known services in NetBeans. Even though this is a foreign application to the included Glassfish and Tomcat, it still offers easy right-click control of the server, including start, stop, deploy and other handy features. It picks up the log as well, in what is not an optimal window for viewing log details in, but one that is acceptable for 90% of the uses you’ll have for it:

The services view here is also notable because you can also access databases (anything that JDBC supports) including the very robust and embed-able Java DB (a.k.a. Derby, formerly known as Cloudscape). 6.1 adds enhanced support for MySQL databases which, given Sun’s purchase of MySQL AB recently, should come as no surprise, but is welcome none-the-less.

Now, let me show you something neat that’s new to 6.1, though likely of interest to a relatively small subset of users:

It’s letting me create an EE5 EJB project in JBoss 4.0.5. A great feature of JBoss 4.0.5 is that it lets you use EJB3, which is an EE5 feature, yet it’s not a full-fledged EE5 container. Previously, creating an EJB3 project in NetBeans for JBoss 4.0.5 would only work if you created an enterprise application, which isn’t always what you want. Finally, it’s good to see NetBeans support this feature that they really shouldn’t have to support, but one that so many of us desired. I’m glad you guys are listening.

JavaServer Faces and the NPE (top)

You’re a Java programmer, so I have little doubt you’ve experienced an NPE, more formally known as a Null Pointer Exception, first hand. NetBeans 6.0 was a huge improvement in my book over 5.5, so I rushed to migrate all my development to it, but one of the two problems that I have with it are rampant NPEs while editing JavaServer Faces (JSF) pages in the JSP editor. This isn’t the VisualWeb stuff (I’ll talk about that in a few), so perhaps that worked in 6.0. This is my style of roll your own JSF on the front end with EJB3 on the back end enterprise applications. Trying to complete managed bean properties within the universally resulted in NPEs and a failure to produce useful matching for managed beans.

This was nearly a deal-breaker for me in 6.0. I do a lot of JSF editing and mis-typing a bean name or property was all too common an occurrence without the bean completion assistance. Redeploy times (especially on JBoss) add considerable length to testing small changes so anything that helps ensure code is correct before being deployed is a great help.

I’m extremely enthused that JSF completion appears to work perfectly again in 6.1. This is pretty much enough to guarantee that I’ll be using it for my primary development work even before it’s out of beta status. As an added bonus it appears that the source navigation for JSP pages has been enhanced and beautified somewhat. Not that it is a particularly highly used function if you’ve templated your pages, but it can help to see where elements are nested in complex documents. It’s certainly a welcome improvement.

Near Hits (top)

A total lack of bugs and frustrations in a new product or version would probably lead me to quit my job as a programmer. It would definitely demonstrate that programming perfection had been achieved, and there would be simply no reason to try for it any longer. So, as marked an improvement as 6.1 appears to be over 6.0, there are still some itches left wanting to be scratched.

Some, like the Swing GUI builder I’ve touched on. Others are perhaps less notable, but perhaps still worth mentioning to interested parties. One is that the system of dockable and floating windows, like the log view window in one of the screenshots above and more critically the component palette and properties windows elsewhere just aren’t as smart as they should be. The properties window disappears when you’re editing code that it doesn’t apply to, but the palette doesn’t. Worse, if you tell the window to float and subsequently it docks, it can re-open itself at times when you’re not expecting it. That’s not a huge problem, but when you’re rapidly building a JSP or JPanel, having windows move unexpectedly is distracting and can even incur errors in your code.

Another is a feature that disappeared between 5.5 and 6.0 which is the Java Bean properties in the project view. It was nice to have the ability to right-click a class and get quick access to a wizard to add or alter standard Java Bean properties. In 6.1 there’s a right-click option to get a “BeanInfo” editor, but in all honesty, I’m having a bit of trouble understanding what it does. It seems to be a replacement for the old functionality, but it also seems to add another layer of complexity to something that was useful because of its simplicity.

Lastly, some time long ago it seems that something happened to make JUnit tests either not work at all in Java library projects (others as well, perhaps), or at least make them not work with a nice simple “run tests” type button. This issue seems to persist even in 6.1, where I’m required to right-click on my test classes and select “Run” in order to get the code to go. At least they run and display the unit test output this way (which wasn’t the case in some of the later 5.x releases if I recall). Still, I don’t quite get why I can just have my nice “run tests” button working. If all my JUnit TestCase classes are in the Test Packages section of the project can’t introspection find them and just run them all? It might just be that I’m doing something wrong, but if that’s the case why is it so unclear to me how I’m supposed to do it?

Itemized Improvements (top)

These are roughly in the order in which they increase my happiness. Whatever that means.

• JSF managed bean property completion works!
• Doesn’t break anything from 6.0
• Adds EJB3 support for EJB projects under JBoss 4.0.x projects
• Starts up much more quickly than 6.0! (4 seconds verses about 10 seconds on my MacBook Pro.)
• Dedicated MySQL Support
• Java bean property editor back (kinda)

Remaining Annoyances (top)

These are roughly in the order in which they decrease my happiness.

• Palette and Property windows still don’t behave like I’d expect
• JUnit tests work, but require some deft clicking to get to run properly
• Matisse builder is still finicky
• Java bean property editor is really weird

Conclusion (top)

Anytime the happy list is bigger than the unhappy list, particularly when the magnitude of the happiness so dwarfs the unhappy, I’m going to go with an upgrade. In this case, if you were holding out on 6.x due to lost features or bugs compared to 5.5, you definitely can’t go wrong by trying it. If you’ve been using Eclipse or IdeaJ, now is a great time to see what all the fuss is about over NetBeans.