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.

Although the Java language already contains two widget toolkits, AWT and Swing, the Eclipse group still chose to implement their own. The detailed reasons for this choice can be found in the Eclipse Overview white paper. However, to prove that this was the right decision, all one needs to do is compare the look-and-feel of a Swing or AWT application of your choice with that of Eclipse. Eclipse looks, feels, and responds like a native application on whatever platform it's running on.

User Interface Framework
To build a graphical interface, SWT can either be used directly or through JFace, the user interface framework of the Eclipse platform. JFace includes dialog, preference, progress reporting, and wizard frameworks as well as image and font registries that make user interface creation very straightforward.

The Eclipse platform supports a multi-window, MDI-like user interface presentation. On top of JFace and SWT the Eclipse workbench provides a framework for building perspectives, editors, and views that provide the structure for user interaction. Editors handle resource lifecycle interactions such as creating, editing, saving, and deleting. Views are used to provide supplementary information about an object with which the user is interacting. Examples include outline, pending tasks, and property views. A perspective is a stacked, tiled, or detached arrangement of views and editors. Only one perspective is visible in a window at a time but you can open multiple windows to view multiple perspectives simultaneously.

The Eclipse user interface framework is extensive, flexible, and powerful. And, even if it doesn't do everything you need, it can easily be extended in less time and with fewer resources than designing and building your own.

Update Manager
Historically one of the biggest problems associated with applications is the support cost incurred to package, distribute, maintain, and upgrade the application as new versions are released. This cost increases when a large and dispersed user community uses the application. With an offering's success and broad deployment, support after the sale can become time-consuming and expensive.

Component maintenance and upgrade facilities were part of the design of Eclipse from the beginning. To control ongoing cost and remove maintenance issues that could become barriers to project development and deployment, the Eclipse platform contains a flexible update manager. The update manager can be configured to initially install new components or updates to existing components from a remote server. As you release new versions of your application or add-on components, distribution can be as easy as packaging them using Eclipse facilities and putting them on your update server.

Help System
Every professional desktop application has a help system for end users and Eclipse is no different. However, Eclipse's help system isn't simply built from a static group of HTML files that document Eclipse. Rather, it's a framework for providing both searchable and context-sensitive help that's open to extension by documentation plug-ins. As a result, for any application built on Eclipse, everything's available for constructing, packaging, and shipping a complete, custom, context-sensitive help system without buying third-party tools.

Using Eclipse as an Application Framework
So starting with the underpinnings of a Java IDE as an application framework may at least sound possible, but why would anyone do it? Well, Eclipse satisfies the full function and facilities wish list mentioned earlier, while providing the program development environment for building the project as a series of Eclipse plug-ins. At the outset the frameworks provide an empty, featureless application that is architecturally sound, extensible for future enhancements, and can upgrade itself remotely.

The main question then becomes how much of Eclipse is required? Simply stated, an application can be built on the Eclipse framework by removing functionality that's not important and adding functionality that is. The more challenging part is where to begin. The easiest cases are in the extremes. For example, when building a commercial IDE, like we do with MyEclipse Enterprise Workbench, it makes sense to start with the complete Eclipse Platform download, as well as a few other Eclipse projects, and build on top of them. At the other extreme, when building an application for an embedded device or any other environment where size constraints are paramount, then either Equinox or eRCP would make a more reasonable starting point. If the deployment target has a few more resources, but still don't require the vast majority of the platform's features then using the RCP (available from the platform download page) as the primary framework is likely the right starting point. With a little configuration on the base RCP you can quickly set up an "empty" application, as shown in Figure 1, and then concentrate on adding only what adds value, rather than infrastructure.

Once the starting platform has been determined, building an application is simply a matter of writing plug-ins to add features to the basic Eclipse framework and branding them appropriately for the intended audience. For example, a large application is typically written as multiple custom perspectives and supporting views using many plug-ins. Alternatively, to integrate a suite of small applications, perhaps each one can be a single perspective in its own plug-in. Along those lines, Eclipse can also be used as a portal to integrate all of a company's homegrown applications. The possibilities are truly endless. And, just to prove the point, here's a very wide assortment of Eclipse-based applications from all over the world.

GumTree is an Open Source graphical user interface framework for building scientific instrumentation consoles as shown in Figure 2.

EclipseTrader is an Open Source set of plug-ins for the Eclipse RCP dedicated to the building of an online stock trading system, featuring shares price watching, intra-day and historical charts with technical analysis indicators, level II/market-depth views, news watching, and integrated trading. The main view is depicted in Figure 3.

Azureus implements the BitTorrent client protocol through Eclipse RCP plug-ins and comes bundled with many invaluable features for both beginners and advanced BitTorrent users. Azureus is typically one of the most downloaded applications at SourceForge and interface looks native on any platform, thanks to SWT, as shown in Figure 4.

Qanyon World Factbook application was written to explore using Eclipse RCP in a distributed environment. Similar to the CIA World Factbook web site, the Qanyon World Factbook should display country information, albeit in a rich client environment, as shown in Figure 5.

Going Forward - What's Next for Eclipse?
Eclipse is continuously evolving and will continue to grow both vertically further into the software tools space and horizontally into completely new market segments. Interestingly, the growth into new industry verticals will be for the same reasons that Eclipse was formed in the first place. Although Eclipse was initially formed to build an integration platform for software tool providers, the separate availability of the RCP changes everything. Rather than being a platform exclusively for tool providers, Eclipse has become a general-purpose platform that has simply been leveraged initially in the software tools arena. With this seminal change, Eclipse will begin drawing participants from other verticals who want to cooperate in the same way that the current group of tool providers has. In the near future I expect to see interest in building infrastructure for productivity applications, reporting tools, security, process workflow, and business intelligence among others. Now that Eclipse is completely open and inclusive across the entire software industry, its membership and growth will explode in the coming years.