From Pain to Gain: Swing and the NetBeans Platform in the Real World
Like most people working with Java since its early beginnings, my first experience with the technology was with (small) desktop applications: some research stuff during my doctorate and a simple control panel for a healthcare call center. It was the age of AWT, and you really couldn’t do much more. So I soon moved to the server side, where things appeared more robust and promising. They were indeed, and I stayed there for long and became a J2EE Architect.
A few years later, I was attracted to the desktop again because of a rising passion for digital photography. I still encountered many problems, but just before I threw in the towel, Sun and the developer community came to the rescue with SwingLabs, java.net and new versions of the NetBeans Platform. Now I am enjoying a (possibly) promising open-source application – blueMarine – which is based on the NetBeans Platform.
In this article, I’ll tell you more about blueMarine’s story and review some of the main NetBeans APIs. I’ll show how these APIs are used and customized, while pointing out the problems I faced and how they were solved. If you don't know much about the NetBeans Platform and you’re involved with desktop development, I think you will enjoy this article, which is republished from the NetBeans Magazine.
Table of Contents
The first time I ever wrote some Java code for managing my photos was around 2001, after getting bored with the OpenOffice spreadsheet I was using. I exported everything to XML and, by means of an XSLT transformation, defined my own database format which was managed by a very simple GUI based on Swing.
In the summer of 2003 I made the "big jump" into the world of digital cameras, buying a Nikon D100 (a professional SLR). It was one of the century’s hottest summers in Italy, so I was forced to minimize the number of photo trips: walking outside was simply a pain. Being forced to stay at home, although in the relaxing environment of the Tuscany countryside, I spent most of my holidays studying the NEF format.
NEF is a "RAW file format" that, at the time, was mostly undocumented. A RAW file format holds the unprocessed data straight from the camera’s CCD sensor and requires processing before being transformed into a quality picture; this processing is often seen as the digital counterpart of the old wet darkroom photo development. Having never owned a wet darkroom, I was intrigued about the possibility of "digitally developing" my photos, and started writing some Java code for this.
At the end of the summer I had created a simple thumbnail navigator with the capability of showing my own photos – and blueMarine was born. A year later, the project had the capability of tagging photos with a catalog facility and of publishing galleries on the web.
However, I was irked by the fact that I needed more than a single piece of software to perform tasks such editing, printing, cataloging, archiving and web publishing. So I set about implementing all this workflow in a single application. Also, I decided it was high time I publicly released blueMarine, and so the first alpha release went on SourceForge under the GPL License (later changed to Apache 2.0). You can see one of the first versions in Figure 1.
Figure 1. The old blueMarine main window, developed on plain Swing.
Another force was pushing me on: the challenge of
trying Java for digital image processing on a desktop computer. To me it was
already evident that Java was good for scientific image manipulation; one
example was that engineers at NASA were successfully using JAI, an advanced
imaging API. But what about desktop processing for the casual photographer? To
demonstrate that Java is good for a wide range of applications is something
that I’ve always been pursuing since I started working as a Java consultant
more than ten years ago.
Notwithstanding the initial enthusiasm, at the end of 2005 I was pretty frustrated with the project. Performance wasn’t much of an issue but I was facing difficulties in developing a rich GUI application using plain Swing. Swing is an excellent API, but when you start using it to build a complex app you discover there’s still a lot of stuff to add.
Implementing the missing pieces is no rocket science, but that work wastes a lot of time better spent elsewhere. Re-instantiate the problem for things such as building menus, having actions enabled in a context-sensitive fashion, defining a flexible and working docking mechanism for internal windows... and you’ll find yourself spending most of your time writing generic GUI components, instead of working on the core of your application.
Until recently, there were few open-source libraries dealing with such issues, and most were unsatisfactory and cumbersome to integrate. There were also the early releases of NetBeans, but I was unsatisfied with their performance. Eclipse and SWT were an option, but I decided I wasn’t really going to study a completely alternative and nonstandard API, with a very low learning ROI and a cumbersome way to integrate with Swing.
Summing up, I was seriously thinking
about giving up with blueMarine – maybe Java wasn’t yet ready for desktop
However, there were a few concurrent events that saved the project: my participation at JavaPolis at the end of 2005, and the release of NetBeans 5.0 in early 2006.
At JavaPolis, I breathed the community atmosphere that I had mostly forgotten (three years had passed since my last JavaOne). This renewed my enthusiasm, which was piqued further by Romain Guy’s presentation showing how effective GUIs can be built with Swing. I started looking at Romain’s blog and by following links I got to other blogs such as Joshua Marinacci’s, and from there to all the java.net and JavaDesktop stuff. I discovered there was a great deal of new interest in Swing; good quality Swing components such as at SwingLabs, cool demos – lots of material that I could use. But I still needed a platform.
A few weeks later, NetBeans 5.0 came out. The new release looked like it had finally fixed the traditional problems of the NetBeans Platform, so I decided to give it a try. I started disassembling blueMarine, extracting only the imaging code and redesigning it to use the NetBeans Platform. After a few months, the first Early Access builds were ready to be delivered, and I had started using the tool for my own photo management. In the meantime, the zero-issues switch from my former PPC Apple iBook to the new Intel MacBook Pro was a strong sign that my choice had been right.
Today I’m working on making the new blueMarine stable and usable. New early access builds are available, and I’m running the required quality tests (the complete redesign obviously broke some of the stability of the previous release; that was the price to pay). Figure 2 shows the NetBeans Platform-based version of blueMarine at work.
Figure 2. The main window of the new blueMarine application, developed on the NetBeans Platform.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)