By now, you've probably heard about Eclipse as "the Open Source Java IDE" (www.eclipse.org). Today, several companies have looked past the Java IDE plug-ins provided as part of Eclipse, and are creating products that use Eclipse as a tool integration platform, both inside and outside of the Java arena. But what about using royalty-free, Open Source Eclipse technology as a general-purpose application framework for your next desktop, fat client, or embedded application? With the support provided by the Eclipse Rich Client Platform (RCP) and the embedded version of the same (eRCP) the idea is certainly not as strange as it first sounds. So we'll explains why Eclipse is a solid desktop, rich-client, or embedded application framework with the potential to greatly simplify and accelerate development as well as forever change the way developers think about writing Java applications.

Software development is often about compromises. Currently, one of the most visible debates centers on the tradeoffs between productivity applications and browser-based UIs. In spite of what current media coverage might lead one to believe, the industry hasn't decided to throw away all its desktop applications in favor of browser-based UIs rendered with some combination of HTML/XML/XSLT/Javascript. The reason can be summed up in three words: "the user experience." Form follows function... is the key criteria for judging usability. In practice, high user interactivity or complex data relationships make delivering user interfaces as a desktop application less of a choice and more of a requirement.

In today's computing environments it's important to deliver user interfaces that can run on a wide variety of platforms. The range is broad - including small handheld devices as well as server consoles. When users interact with applications in the window management environments they're most familiar with, using the application must feel natural and predictable.

Building a productivity application means starting with a good design and a supportive architecture. Since there's no universally accepted application framework, most developers design their own architecture and then build it into a framework. However, the cost of this approach is considerable expense, time, debugging, support, and aggravation expended on solving a problem that's peripheral to building the functionality of the intended application.

A much better approach than "rolling your own" application framework would be to find one that could fulfill the design requirements while simplifying and accelerating project development. A "wish list" for such a framework would likely contain the following:

• Implements a clear, consistent, and cohesive architecture
• Supports development and execution on all the major desktop platforms (Windows, Mac OS X, Linux, QNX Photon, Pocket PC, HP-UX, AIX, Solaris)
• A snappy UI response that maintains the platform's native look-and-feel
• Provides a large variety of widgets, both standard (i.e., button and checkbox) and extended (i.e., toolbar, tree view, and progress meter)
• Provides extensive text processing that includes editors, position/change management, rule-based styling, content completion, formatting, searching, and hover help
• Supports using platform-specific features (i.e., ActiveX) and legacy software, if desired
• Enables branding the application
• Contains an integrated help system
• Manages user configuration and preferences
• Supports remote discovery and installation of application updates
• Created and backed by respected software companies experienced in creating object oriented frameworks
• Supports internationalization and national language translation
• Designed for flexibility with natural features for adding new functionality
• "Pay" only for what you need - base frameworks can be easily reduced as well as extended to tailor capabilities to precise requirements

To complete our "wish list" we might as well add that the technology be used and supported by a multi-industry charitable foundation, created and maintained by an Open Source community, royalty-free and licensed to provide worldwide redistribution rights. Although these requirements may sound like a pipe dream, it's likely that Java application developers already have this incredible application framework installed. It's Eclipse.

Can Eclipse Be Used as an Application Framework?
The Eclipse Project FAQ say "The Eclipse Project is an Open Source software development project dedicated to providing a robust, full-featured, commercial-quality industry platform for the development of highly integrated tools." So by definition, Eclipse is an open platform for tools integration, not an IDE. The issue has been confused because a complete industrial-strength Java IDE is available in the Eclipse Platform in the form of plug-in components that extend Eclipse's basic framework facilities.

Eclipse provides the framework for combining disparate tools into a single integrated application with a seamless user interface. New tools are integrated into the Eclipse Platform and its user interface through plug-ins that extend Eclipse's facilities and provide new functionality. Eclipse plug-ins can also extend other plug-ins. When an Eclipse-based application initializes, it discovers and activates all of the plug-ins that have been configured for the environment. An Eclipse application is quite literally the sum of its parts since it's capable of performing any function that has been added to it by the plug-ins it currently contains.

Since being able to write and test such plug-ins is essential to the success of Eclipse, the Eclipse Platform is bundled with a plug-in development environment (PDE) and a set of Java development tools (JDT) to support it. Eclipse's developers clearly trusted the power of the frameworks they created. The entire development environment is just another set of tools integrated into the platform using the standard plug-in techniques. The Eclipse Platform itself was itself created by developers using the Eclipse-based Java IDE (initially in beta form). And, since it's Open Source, anyone can inspect the code and understand in great detail exactly how the frameworks are supposed to be used.

It's this practice of packaging the development tools with the platform that causes some people to be confused about the nature of Eclipse. The JDT components are so effective that they're attractive to all Java developers, not just those writing plug-ins. On the surface, Eclipse appears to be just an excellent Java IDE. But instead of thinking about Eclipse simply as a Java IDE, try to think about it as a productivity application that happens to include a Java IDE built using the underlying Eclipse Platform as an application framework.

Eclipse Framework Features
Eclipse embodies an extensible design that maximizes its flexibility as an architectural platform. At its core, the Eclipse Platform contains an efficient implementation of the OSGi R4 core framework specification known as Equinox, which is used to bootstrap the application. Up from that, the Eclipse architecture defines sets of layered subsystems that allow it to be used as a framework for a portable application (or suite) that's not an IDE at all. And, since the frameworks are layered and coupled only at distinct architectural interfaces, an application can be built by combining only the frameworks it needs, while eliminating those that it doesn't.

The following sections describe the primary Eclipse features that make it attractive as a general application framework.

Extensibility Model
Requirements change over time so developers often expend considerable effort designing applications so that they're flexible and extensible. Eclipse is built around a highly flexible and extensible plug-in model so any type of capability can be added to the platform. If an application can be thought of as a tool, or set of tools, it immediately becomes apparent that its functionality can be added to an Eclipse-based framework as a set of plug-ins just as Eclipse's native Java IDE capabilities have been.

Content Model
Eclipse provides a content model built around the concept of a workbench in which tools (capabilities) can be installed. The tools operate on resources organized into projects in the workspace. Projects contain a tree structure of resources, which are folders and files containing any type of content. The core platform provides a large number of extension points that allow the customization of all aspects of resource lifecycle management.

The hierarchical, categorized nature of the content model lends itself to many kinds of productivity applications with a bit of thought. For example, a simple e-mail client could be built on a workspace that contains a single project associated with the user's e-mail account. The user's project could contain folders for common functional e-mail elements such as inbox, outbox, and sent items. Each of these folders could contain the corresponding set of e-mail messages as project resources.

Native Widgets
The Eclipse platform contains a standard widget toolkit, SWT, implemented natively on all supported Eclipse platforms. SWT contains a large set of events, layout managers, and widgets. When a supported platform doesn't contain a native widget supported by Eclipse, such as a toolbar on Motif, an emulated widget for that platform is provided. SWT also interacts with native desktop features, such as drag-and-drop. SWT can also use OS-specific components, such as Windows Active/X controls, if such functionality is more desirable than full platform portability. So far, SWT has been proven on the Windows Win32 and Pocket PC, Photon, Motif, and GNU window managers, covering deployment platforms from high-end workstations to embedded devices.