Contents: Why a new IDE Platform? The Eclipse Platform Figure 2: The Eclipse Workbench Starting up Eclipse Extending the Platform Running the Platform Summary Resources About the author Rate this article Related content: Subscribe to the developerWorks newsletter developerWorks Toolbox subscription Also in the Java zone: Tutorials Tools and products Code and components Articles

Rawn Shah (rawn@us.ibm.com)

March 29, 2003

The Eclipse Platform provides an open universal framework for building developer tools. This article describes provides an introduction to the platform and shows how it operates.

The Eclipse Platform is a fresh start with the first well-designed open integrated development environment (IDE) system in quite a while. While classic tools like Emacs and others have supported the development needs of developers worldwide, most lacked the fine-edge features of the graphical IDEs, as well as an extensible nature, available in commercial tools. Eclipse stands a chance to change that entirely.

The Eclipse Platform is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as Web sites, embedded JavaTM programs, C++ programs, and Enterprise JavaBeans.

Yet, it is not an IDE in itself, rather a platform to build IDEs through a plug-in architecture. This facet is what has made existing applications like Emacs so useful, although rather than the cryptic Lisp coding necessary to build libraries for Emacs, it supports the more well-known Java language.

Why a new IDE Platform?
The recent mass popularization of the Internet has led to the rise of new technologies, programming languages, and design systems that have usually required separate tools to work with. These days, a developer may have to write programs in Java, Python, C++ and others, all to support a single application. An enterprise application can employ Enterprise Java Beans, HTML, XML, JavaScript, Java Server Pages, and more, within the context of providing services to their customers through their Web site.

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 this comes different user interfaces, and different ways of doing things, thus only complicating the lives of developers.

The idea of a single tool that can allow a developer to work with multiple programming environment needs, has become an unworded need of late. It’s quite unlikely that one company can create such a tool that will satisfy the needs of all developers for all functions. However, if you can solve the problem of unifying the interface and the platform for all the tools a developer will need, you can make their lives much easier. A happy developer is a productive developer. The obvious conclusion to this is that projects may be completed faster with code that is easier to handle the next time around.

There are yet more benefits to a tool environment platform like Eclipse as described in the related paper (see Resources).

The Eclipse Platform
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 (e.g., HTML, Java, C, JSP, EJB, XML, etc.)
• 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 LinuxTM.
• Capitalize on the popularity of the Java programming language for writing tools.

The Eclipse 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.

A plug-in is the smallest unit of function that can be developed and delivered separately in the platform. A simple tool, such as one to translate plain text documents to HTML, might be written in a single plug-in. A more complex tool like a Java IDE would likely split its functionality across multiple plug-ins. All of the Eclipse Platforms functions are located within plug-ins, except for the core Platform Runtime.

Plug-ins are coded in Java. A typical plug-in consists of Java code in a JAR library, some read-only files, and other resources such as images, Web templates, message catalogs, native code libraries, etc. Some plug-ins may not contain code at all. One such example is a plug-in that contributes online help in the form of HTML pages.

A single plug-in's code libraries and read-only content are located together in a directory in the file system, or at a base URL on a server. There is also a mechanism that permits a plug-in to be synthesized from several separate programs, each in their own directory or URL. This, for example is the mechanism used to deliver separate packs for an internationalized plug-in to support environments in multiple human languages.

Each plug-in has a manifest file declaring its interconnections to other plug-ins. The interconnection model is fairly 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.

A plug-in’s extension points can also be extended by other plug-ins. For example, the Workbench plug-in declares an extension point for user preferences. Any plug-in can contribute its own user preferences by defining extensions to this point.

An extension point may have a corresponding API interface. Other plug-ins can contribute implementations of this interface via extensions to this extension point. Any plug-in is free to define new extension points and to provide a new API for other plug-ins to use.

The major components of the Eclipse Platform, as shown in Figure 1, are:

• 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

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 is shown in Figure 2. The VCM is necessary for both single-user and team development environments.

Figure 2: The Eclipse Workbench

You should read the full discussion of the architecture of Eclipse and its components, available in a related paper (see Resources).

Starting up Eclipse
On start up, the Platform Runtime discovers the set of available plug-ins, reads their manifest files, and builds an in-memory plug-in registry. The Platform matches extension declarations by name with their corresponding extension point declarations. Any problems, such as extensions to missing extension points, are detected and logged. The resulting plug-in registry is available via the Platform API. Plug-ins cannot be added after start-up.

Plug-in manifest files contain 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 other plug-in that is declaring the corresponding extension point.

Moreover, 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 only some of which are needed in any given user session.

Until a plug-in's code is loaded, it has a negligible memory footprint and impact on start up time. 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.

A plug-in is activated when its code actually needs to be run. Once activated, a plug-in uses the plug-in registry to discover and access the extensions contributed to its extension points. For example, the plug-in declaring the user preference extension point can discover all the user-contributed preferences and access their display names to construct a preference dialog. This can be done using only the information from the registry, without having to activate any of the contributing plug-ins. The contributing plug-in will be activated when the user selects a preference from a list. Activating plug-ins in this manner does not happen automatically; there are a small number of API methods for explicitly activating plug-ins. Once activated, a plug-in remains active until the Platform shuts down. Each plug-in is furnished with a subdirectory in which to store plug-in-specific data; this mechanism allows a plug-in to carry over important state information between runs of the platform.

Extending the Platform
The Platform Runtime declares a special extension point for applications. When an instance of the Platform is launched, the name of an application is specified via the command line; the only plug-in that gets activated initially is the one that declares that application.

By determining the set of available plug-ins up front, and by supporting a significant exchange of information between plug-ins without having to activate any of them, the Platform can provide each plug-in with a rich source of pertinent information about the context in which it is operating. This context cannot change while the Platform is running, so there is no need for complex life cycle events to inform plug-ins when the context changes. Through this system, the platform avoids a lengthy start-up sequence, which is a common source of bugs stemming from unpredictable plug-in activation order. This is one of the problems that causes what is colloquially known as DLL-Hell, when applications crash because of a confusion with the plug-ins and libraries that they use.

Running the Platform
The Eclipse Platform runs within a single invocation of a standard Java virtual machine. Each plug-in is assigned its own Java class loader that is solely responsible for loading its classes and Java resource bundles. Each plug-in explicitly declares its dependence on other plug-ins from which it expects to directly access classes. A plug-in controls the visibility of the public classes and interfaces in its libraries. This information is declared in the plug-in manifest file, and the plug-in visibility rules are enforced at run-time by the plug-in class loaders.

The plug-in mechanism is used to partition the Eclipse Platform itself. The Workspace, Workbench, and other components are each a separate plug-in. Even the Platform Runtime itself has its own plug-in. Non-GUI configurations of the Platform may simply omit the Workbench plug-in and its dependent plug-ins.

The Eclipse Platform's update manager downloads and installs new components or upgraded versions of existing components. The update manager constructs a new configuration of available plug-ins to be used the next time the Eclipse Platform is launched. If the result of upgrading or installing proves unsatisfactory, the user can roll back to an earlier configuration.

The Eclipse Platform Runtime also provides a mechanism for extending objects dynamically. A class that implements an adaptable interface declares its instances open to third party behavior extensions. An adaptable instance can be queried for the adapter object that implements that interface or class. For example, Workspace resources are adaptable objects; the Workbench adds adapters that provide a suitable icon and text label for a resource.

Any party can add behavior to existing types (both classes and interfaces) of adaptable objects by registering a suitable adapter factory with the Platform. Multiple parties can independently extend the same adaptable objects, each for a different purpose. When an adapter for a given interface is requested, the Platform identifies and invokes the appropriate factory to create it. The mechanism uses only the Java type of the adaptable object; it does not increase the adaptable object's memory footprint. Any plug-in can exploit this mechanism to add behavior to existing adaptable objects, and to define new types of adaptable objects for other plug-ins to use and possibly extend.

When all the plug-ins are loaded, the developer is faced with the capabilities of the environment that is melding of all the features of the plug-ins. Changing their development environment or adding new features is a simple switch of plug-ins and a restart of Eclipse.

Summary
The Eclipse Platform provides a firm foundation of generic building blocks and APIs, and various extension points through which new functionality 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 Independent Software Vendors can build the necessary tools for the developers who use them. 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 they can customize for their own development needs using tools from different vendors and be assured that they not only work together but work well.

Resources

• The Eclipse Platform architecture paper details the various basic components that make up the platform [[Production: this other paper is coming from me]]
  
  
• The Eclipse Web site http://www.eclipse.org has details on how to get the platform, and where to get more information about it.
  
  

What do you think of this document? Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1) Comments?

IBM developerWorks > Java technology