The Eclipse Platform is a fresh start at an open integrated development environment (IDE) system with broad commercial participation. While classic tools like Emacs and others have supported the development needs of developers worldwide, most lacked the advanced features and convenience of GUI based IDEs, as well as an easily extensible nature, available in commercial tools. With over 1200 developers from 63 countries involved in the Eclipse open source community process and with more than 150 leading software tools vendors working with it, Eclipse stands a chance to change that entirely.
This article describes the basic structure of the Eclipse platform and how it operates. It is expanded on further in the white paper published by the Eclipse Development Team (see Resources).
To accomplish this, they often have to rely on multiple programming tools either because of the lack of features and capabilities in a single tool, or because some such tools provide better functionality than others. With each separate tool comes a different user interface, and different ways of doing things, thus only complicating the lives of developers.
The Eclipse Platform is a kind of universal tool platform -- an open extensible IDE (integrated development environment) for anything but nothing in particular. The real value of the Eclipse platform comes from the many tool plug-ins that each "teach" Eclipse how to work with things -- Java source code, OO models, Web content, XML, graphics, workflow processes, video -- almost anything you can imagine. Tools built as Eclipse Platforms plug-ins interact with both the platform and other tools. This can provide users with a seamless work experience. In fact, a user may not even realize where one tool starts and another begins.
The Eclipse Platform is designed and built to meet the following basic requirements:
- Support the construction of a variety of tools for application development.
- Support an unrestricted set of tool providers, including independent software vendors.
- Support tools to manipulate arbitrary content types.
- Facilitate seamless integration of tools within and across different content types and tool providers.
- Support both GUI and non-GUI-based application development environments.
- Run on a wide range of operating systems, including Windows® and Linux®.
- Capitalize on the popularity of the Java programming language for writing tools.
The platform's principal role is to provide tool providers with mechanisms to use, and rules to follow, that lead to seamlessly-integrated tools. These mechanisms are exposed via well-defined API interfaces, classes, and methods. The Platform also provides useful building blocks and frameworks that facilitate developing new tools.
The Eclipse Platform has no specific knowledge about any domain, and is not limited to Java language applications. However, the Eclipse SDK includes the Eclipse Platform, a Java Development Tool (JDT) and the Plug-in Development Environment (PDE). The JDT and PDE are plug-ins to the Platform.
The Eclipse Platform is built on a mechanism for discovering, integrating, and running plug-ins. A plug-in is the smallest unit of function that can be developed and delivered separately. Usually a small tool is written as a single plug-in, whereas a complex tool has its functional split across several plug-ins. The JDT consists of five functional plug-ins and two documentation plug-ins.
When the Platform is launched, the user is presented with an integrated development environment (IDE) composed of the set of available plug-ins. Except for a small kernel known as the Platform Runtime, all of the Eclipse Platform's functionality is located in plug-ins. This means the Platform plays by exactly the same rules as all of the other plug-ins, no magic, no cheating.
Plug-ins are coded in Java programming language. Each plug-in has a manifest file declaring its interconnections to other plug-ins. The interconnection model is simple: a plug-in declares any number of named extension points, and any number of extensions to one or more extension points in other plug-ins. An extension point may have a corresponding API interface. Put simply, an extension point says "here is a slot for you to provide me with new behavior," and an extension says "here is the new behavior you asked for."
Plug-ins can even take on both roles by declaring the extension point and providing the extensions to it. In fact, most of the Eclipse Platform's own user interface is done exactly this way. Plug-ins, their extension points and extensions conspire with the Platform's well-defined API to provide tool writers an open system that treats extensibility as a truly first class notion. The JDT and PDE make it easy create your own plug-ins, extension points and extensions.
Tools written as Eclipse Platform plug-ins in Java programming language achieve the highest level of integration with the Platform. Thanks to the Eclipse Platform's design flexibility, it's even possible to write plug-ins that launch and integrate external tools. Even external tools have levels of integration with the Eclipse Platform through facilities like OLE and ActiveX on Windows. Obviously, tools written in this way become dependent on the underlying operating system that provides these services. External tools must manage their own separate GUI windows.
The major components of the Eclipse Platform, as shown in Figure 1:
- the Platform Runtime
- the Workbench which implements the graphical interface to Eclipse, and its subcomponents JFace and the Standard Widget Toolkit (SWT)
- the Workspace that "holds" the development environment
- the Help system
- the Version and Configuration Management (VCM) system
Figure 1. The Eclipse Platform architecture
All of these components are necessary for the GUI version of the Eclipse Platform. A text version would not need the Workbench graphical features but can provide the same user environment located in the Workspace. A screenshot of the GUI Eclipse Workbench running under Linux is shown in Figure 2. A similar workbench running under Windows is shown in Figure 3. The VCM is necessary for both single-user and team development environments.
Figure 2. The Eclipse Workbench Running under Linux
Figure 3. The Eclipse WorkBench Running under Windows
On start up, the Platform Runtime discovers the set of available plug-ins and builds a plug-in registry. Plug-in manifest files are defined in XML. An extension point may declare additional specialized XML element types for use in the extensions. This allows the plug-in supplying the extension to communicate arbitrary information to the plug-in declaring the corresponding extension point.
Manifest information is available from the plug-in registry without activating the contributing plug-in or loading of any of its code. This property is key to supporting a large base of installed plug-ins since only a few are usually needed within any given user session. Until a plug-in's code is activated, it has a negligible memory footprint and impact on start up time.
Once activated, a plug-in uses the plug-in registry to discover and access the extensions contributed to its own extension point. Using an XML-based plug-in manifest also makes it easier to write tools that support plug-in creation. The Plug-In Development Environment (PDE), which is included in the Eclipse SDK, is such a tool.
Since developers spend most of the time right at their workstations, tools need to run fast, with a responsive look and feel. The Eclipse Platform has been engineered with a new and very efficient set of GUI construction widgets. These are available to anyone implementing tools on the Eclipse Platform. The Standard Widget Toolkit (SWT) is a widget set and graphics library integrated as much as possible with the native window system but with an OS-independent API. JFace is a higher level user interface construction toolkit implemented using SWT. JFace greatly simplifies common UI programming tasks.
The entire Eclipse Platform UI, and the tools that plug in to it, use SWT for presenting information to the user. This is true for all tools execution environments, including Linux, Microsoft Windows and other operating system platform-based workstations with a graphical environment. So, the Eclipse Platform successfully delivers high performance and Platform transportability without turning to inefficient layered and emulated user interface techniques.
An important side benefit of using SWT is that once you've developed a user interface on Linux, it is also a first class interface when applied to Windows. The reverse is also true.
The Eclipse Platform user interfaces are based on editors, views, and perspectives. From the user's standpoint, a Workbench window visually consists of several views and editors. Perspectives manifest themselves in the selection and arrangements of editors and views visible on the screen.
Editors allow the user to open, edit, and save objects and files. Views provide information about some object that the user is working with in the workbench. A view may assist an editor by providing information about the document being edited. A Workbench window can have several separate perspectives, only one of which is visible at any given moment. Perspectives arrange groups of and editors for presentation on the screen.
The Eclipse Platform incorporates the concept of a "workspace" that maintains everything needed by the developer for building and testing a project. The workspace is locally maintained on a developer's own workstation, containing the configuration settings of tools plug-ins, the data objects being edited and the intermediate and completed form of the components being developed. The use of a local workspace allows for very efficient team collaboration through repositories that can be Internet -- rather than LAN-accessible.
The team support model centers on repositories that store version-managed resources on shared servers. While it does not provide its own repository system, the Eclipse Platform is designed to concurrently support a range of different repository types. A single workspace can access different types of repositories simultaneously. The team development support component of the Eclipse Platform adds version and configuration management (VCM) capabilities to projects in the Workspace. The team collaboration support model allows a developer to concurrently interact with several separate repositories and versions of a resource. Most tools simply operate on resources within the Workspace, allowing the team support component to deal with version and configuration management issues.
The Eclipse Platform provides a firm foundation of generic building blocks and APIs, and various extension points through which new development facilities can be integrated. Through these extension points, tools written as separate plug-ins can extend the entire Eclipse Platform itself.
The idea of Eclipse is to lay the groundwork whereby different companies and ISVs can build the necessary tools that developers can use. This means that each participant company will save a significant amount of time when bringing new tools to developers, while also allowing them to integrate with those tools from other companies.
The developer, thus, gets an IDE that can be customized to meet personal development needs using tools from different vendors and be assured that they not only work together but they work well together.
- You can join the Eclipse community and download this new open source IDE at the Eclipse.org site. The Eclipse Platform source code is licensed under the Common Public License. The Eclipse CPL is based largely on the IBM Public License, V1.0. This license was certified for use by the Open Source Initiative (carrying the "OSI Certified" mark).
- At Eclipse.org you'll also find a description of Eclipse projects, along with technical articles and newsgroups.
- The Eclipse Platform white paper describes in detail the major components and functions of Eclipse.
- This interview with an IBM project manager assigned to assist the Eclipse Project, Marc Erickson, explains more about the goals of Eclipse.
- Read Daniel Steinberg's article "Refactoring with Eclipse."
Now in his 28th year at IBM, Marc Erickson is a graduate of Southern Illinois University holding degrees in Data Systems Management and Data Processing. He joined IBM subsidiary Object Technologies International as a project manager in 1999 to focus on the embedded computing and software development tools marketplace. He now serves on the ANSI committee studying standards for the software development process, and represents IBM on the Java Community Process Executive Committee for J2ME. You can contact him at firstname.lastname@example.org.