|Working the Eclipse Platform|
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 Java programs, C++ programs, and Enterprise JavaBeans technology.
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 programming language.
Why a new IDE Platform?
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'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 programming language. 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:
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.
You should read the full discussion of the architecture of Eclipse and its components, available in a related paper (see Resources).
Starting up Eclipse
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
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 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 technologies 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.
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.