February 18, 2019
Hot Topics:

Meet Eclipse

  • July 6, 2005
  • By Peter Nehrer
  • Send Email »
  • More Articles »

Platform Architecture

It may come as no surprise that the Eclipse platform architecture is conceptually neither new nor unique. It is a modular, flexible architecture built along the principles of interface-driven design. At its core, Eclipse sports an Open Services Gateway initiative (OSGi) runtime, which is a micro-kernel-like layer whose sole responsibility is to provide an execution environment for the so-called bundles, or plugins, in Eclipse speak. Plugins are the basic units of functionality within Eclipse. When activated, they collaborate together through their pre-defined interfaces to provide the overall application functionality. Even the most fundamental logic in Eclipse—such as discovering and activating configured plugins—is encapsulated in a bundle. This tried-and-true modular design is characteristic of many successful platforms, tools, and applications.

To better support extensibility, Eclipse uses the concept of extensions and extension points. An extension point allows a plugin to expose properties and interfaces for which other plugins may provide the actual values and implementation, respectively—or plug themselves in (hence the term). A plugin declares that it implements a particular extension point by the way of an extension. Rather than a simple Java interface, an extension point may consist of an entire set of properties (an extension is really an XML document fragment whose structure is defined an an XML Schema-like manner). Like plugins, extension points in a system must be uniquely identified.

As it is the case in many other component-based systems, a plugin runtime characteristics are described in its descriptor, or manifest. As of Eclipse 3.0, the plugin descriptor is split into two files: a manifest (in /META-INF/MANIFEST.MF), which contains the plugin runtime environment properties, such as its unique identifier, version and classpath dependencies, and plugin.xml, which contains its extensions and extension point declarations (the actual definition of an extension point lives in a separate XML Schema-like file). These two files also differ in that the MANIFEST.MF is a plain-text file with the JAR manifest format, whereas the plugin.xml is an XML document.

Some of the most important components in Eclipse are the Platform runtime, Workspace (Resource model), Help, SWT, JFace, and Workbench. Although the details of each are beyond the scope of this article (you will examine some of them in subsequent installments when you learn about developing plugins), one thing is worth mentioning. What makes Eclipse unique among many other Java-based solutions is its native look-and-feel. Eclipse doesn't just faithfully simulate the native look-and-feel of the host platform; it actually uses the platform's native widget set and windowing system—it's the real deal! This is thanks to the SWT framework that provides an abstraction of the most common widgets available in platforms where Java is supported. The implementation of these widgets is platform-specific—the SWT library is linked to the host platform's widget implementation through the Java Native Interface (JNI).

Just like other parts of Eclipse, its platform architecture continues to evolve. For example, prior to release 3.0, Eclipse had a custom runtime layer that caused potential problems when integrating it into other environments. Starting with 3.0, this was replaced by an OSGi-compliant implementation developed by the Equinox project. Another example is the recent refactoring of the extension registry, which was found to not scale well with large number of installed plugins (to the extent that the development team didn't initially anticipate). Improvements such as these are continuously incorporated into the platform and result in better performance, compatibility, and usability.

Who Dunnit

To better understand the community around Eclipse that exists today, you must take a brief look at how it evolved. As many of the folks involved with Eclipse from the beginning like to say, it didn't happen overnight. Its initial codebase came from a Canadian company called Object Technology International, now a wholly owned subsidiary of IBM. OTI was tasked with creating a tool platform that would unify the various technologies behind IBM's VisualAge product line. In November of 2001, IBM caused quite a splash when it announced the release of Eclipse as open-source. A consortium of several companies was formed to oversee further development of Eclipse, with the objective to foster the creation of an entire eco-system of contributors, consumers, add-in providers, and other participants. The Eclipse Consortium grew steadily in the years that followed, with a number of new member companies coming on board.

The momentum behind Eclipse really picked up when, in February of 2004, Eclipse was reorganized into a not-for-profit organization, the Eclipse Foundation. This move made Eclipse formally independent of IBM and encouraged other companies, which may have seen themselves as direct or indirect competitors of IBM, to get on board. Today, the Eclipse Foundation is made up of nine Strategic Developers, four Strategic Consumers, 62 Add-In Providers, and 11 Associates. The Foundation's organizational structure, development process, as well as roles and responsibilities of the various membership classes are defined in its formal governance documents.

While membership fees, hardware donations, and direct software contributions from the member companies are essential for the Foundation's survival, it's the people involved in it that really make it work. The Board of Directors, various councils, committees, and project teams are made up of member company representatives as well as independent committers. The actual Java code is contributed by Committers—individual developers with access rights to the source code repository; only a Committer can make changes to source files. Just who can become a Committer depends on the specific by-laws and rules of a particular project or sub-project. An interesting (and very beneficial) provision in the Foundation's by-laws reserves three seats on the Board of Directors for Elected Committer Representatives, who make sure that the interests of their constituents (whether independent or employees of a member company) are represented at the highest level.

Aside from making Eclipse downloads available to the public, the Foundation provides tools and infrastructure to support the development of its projects. Typically, each project gets a CVS repository for source code versioning, a newsgroup, and a mailing list to facilitate communication with the community, and Web space for publishing project-specific information, such as documentation, build instructions, development plans, and so on. Each project is also set up in the Bugzilla database, which helps keep track of user-submitted bug reports and feature requests. In addition to project-specific pages, the Web site contains information about the Foundation as well as the greater community, provides Web-based access to the various newsgroups and archived mailing lists, and last but not least, makes available a sizable list of high-quality articles covering a wide range of Eclipse-related topics, authored by subject-matter experts.

The Eclipse community extends far beyond the Eclipse Foundation. There is an ever-growing number of Web sites, blogs, wikis, newsletters, articles, magazine columns, published books, and open-source projects that are in one way or another related to Eclipse. A growing number of commercial enterprises adopt Eclipse not only as their development environment, but as an integrated tool or rich client platform as well. By all indications, the Eclipse community is healthy and growing even stronger. If you decided to download and try the Eclipse SDK, you too became an important part of that community—the end user. Becoming actively involved is actually quite easy—use Eclipse frequently and report any bugs or problems you run into. If you can, download the latest milestone builds and/or release candidates and help improve the product before its final release.

Commercial-Friendly Open-Source

An important contributor to the success of Eclipse is its licensing model. In the end, developing all this great software would come to no avail if its adoption was hindered by overly restrictive licensing. All Eclipse code is released under the Eclipse Public License (EPL), which makes both the source code and binaries available free of charge and grants full redistribution rights to both open-source and commercial adopters. Basically, anyone is free to use Eclipse in any way they see fit, provided that any modifications to the original source code are also made available under EPL (note that this does not mean that any custom extensions or plugins need to be licensed under EPL).

While its licensing model makes Eclipse attractive to a large base of potential adopters, it presents a challenge to its developers—the codebase must not be "contaminated" by contributions with incompatible licensing constraints. In fact, committers submitting code contributions must go over a pre-defined checklist that ensures that the contributed code is EPL-compatible. The problem arises when a project wants to re-use existing work released under an incompatible license. After all, nobody in the community wants to waste their valuable time and resources reinventing the wheel, and thus all efforts are made to use existing libraries whenever appropriate. Although Eclipse already identified a number of compatible licenses and is able to use many popular open-source libraries, such as ANT, Apache Tomcat, and others, the problem persists especially for new projects, many of which are testing waters with licenses that were not previously encountered. At the moment, the Foundation is working intensively to resolve this problem.

What's Ahead

Unlike astronomers, who can predict celestial events with high accuracy and a long way into the future, no one in the software industry knows exactly what will happen with Eclipse. Today, one thing is clear: Eclipse has already met and even exceeded many of its initial expectations. Its thriving eco-system is a proof that contributing previously proprietary technologies to a common open-source platform is advantageous even to vendors whose end-user offerings are often in direct competition with one another. Eclipse's software development model also turned out to be applicable to more than a tool integration platform—an entirely new, general platform for developing rich client applications has emerged, with the potential to revive Java on the desktop.

One of the challenges Eclipse faces today is managing its own rapid growth—but that's a nice problem to have! Each new contributing company brings along its own development style and practices. The rules, policies, and processes established by the Foundation will be exercised to their full extent. Fortunately, just like its source code, they too are open to public review and scrutiny, which gives Eclipse the best chances of success.


Eclipse is an open-source project that delivers one of the best Java IDEs available today, a platform for integrated software development tools, a foundation for building rich client applications, and a collection of best-of-breed technologies for creating robust and innovative applications. It has a vibrant community of contributors, users, and commercial vendors that is rapidly expanding. With an increasing momentum behind it, Eclipse is poised for continued success.

In the next installment of this series, you will take a closer look at the Eclipse Workbench and Java Development Tools. In particular, you will examine what it takes to create, test, and debug simple Java applications using Eclipse.


  1. Eclipse Web site: http://www.eclipse.org
  2. Planet Eclipse: http://www.planeteclipse.org
  3. Eclipse Plugin Central: http://www.eclipseplugincentral.com
  4. EclipsePlugins: http://eclipse-plugins.info
  5. Eclipse Zone: http://www.eclipsezone.com
  6. IBM developerWorks: http://www.ibm.com/developerWorks

About the Author

Peter Nehrer is a software consultant living in Toronto, Ontario. He specializes in Eclipse-based enterprise solutions and J2EE applications. His professional interests include development tools, model-driven software development, and information sharing. He is the author and contributor to several Eclipse-related Open Source projects. Peter is an IBM Certified Solutons Developer for XML and related technologies. He holds an M.S. in Computer Science from the University of Massachusetts at Amherst, MA.

Page 3 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date