email article printer friendly

Java's Desktop Comeback
New vertical market applications require customization, and the RCP may provide the best tools for the job
by Peter Varhol

May 8, 2006

Eclipse has one. NetBeans has one. Eclipse claims to have made significant strides in getting developers excited about the technology and using it in development efforts. I'm not referring to a freely available open source IDE, of course, but rather the Rich Client Platform (RCP).

You can think of the RCP as an application framework. How does it work, you might ask? Both Eclipse and NetBeans are fundamentally IDEs, looking and behaving the way developers expect them to perform. While Eclipse has shifted its image over the last couple of years to that of a more generic application development platform, the concept of the RCP doesn't even seem to fit under that umbrella.

Further, the recent promotion of the Java rich client seems odd, coming as it does after the development community seems to have determined that Java is best suited for Web applications and middleware. Once upon a time, in the dawn of the Internet era, Java was in fact seen as primarily a platform for visual experiences. This notion was supported by a rich set of layout managers that in theory enabled developers to deploy the same UI on different display types such as desktop computers and cell phones.

However, Java on the desktop or in applet form suffered from poor user interface (UI) controls, inconsistent layout managers, and above all, poor performance. Within two years, Java largely disappeared from the desktop, and still later Java 2 provided the features needed for true enterprise back-end solutions. Except for Web applications, Java almost disappeared from the desktop.

Ch-Ch-Changes
What has changed? Fortunately, plenty. Here are probably the three most important changes we've experienced in the platform in the last ten years.

1. Managed languages are mature. Let's face it, Java was painfully slow in the 1.0 time frame. Bytecode was fully interpreted, whereas today just about everyone JITs it. Likewise, early versions of the Java Virtual Machine (JVM) were not tuned for performance. The concept of managed languages was new for most, and expectations were based on the relative performance of C and C++ applications. Java clearly suffered as a result. However, today managed languages are the mainstream. Microsoft has introduced its own managed platform, and it is no longer such a radical idea. Scripting languages such as Python and Ruby, which are interpreted, are accepted as solutions that provide for sufficient performance and scalability on many different applications. Running Java on the desktop is no more foolish than running Microsoft on the desktop.

2. Computers and networks are faster. The poor performance of Java was exacerbated by slow desktop computers. While they may have seemed pretty fast at the time, the average computer in 1996 ran at about 133 MHz and had about 8 MB of memory. That amount was insufficient memory to contain an adequate working set for both a JVM and an application, so the result was a lot of disk swapping and waiting. Networks had similar limitations, especially with Internet access. Anyone who tried running Web applets across dial-up networks around 1996 knows that download speeds were painfully slow. In contrast, today the proliferation of T1 lines, frame-relay networks, DSL, and cable modems make Internet access blazingly fast, and for LANs, gigabit Ethernet is fast becoming the standard.

3. User interface choices are better. When Java first launched, its UI controls were primitive and without many properties that developers expected to have under their control. On the Eclipse platform, the Simple Widget Toolkit (SWT) provides the Windows look and feel that is familiar to most computer users, and on NetBeans developers are more than happy with Swing.