You’ve seen it in the headlines. You know colleagues who use it. Maybe you even gave it a try. These days, most of the Java world seems to talk about it. But what exactly is it?
This article is the first in a series that will take you on a guided tour of Eclipse. With its recent 3.1 release, Eclipse is solidifying its position as one of the most popular Java development environments and broadening its reach into the rich client space. Its developer community is growing rapidly and the momentum behind Eclipse is strong as ever. In this installment, you will look at Eclipse as a project—what technologies it provides, how it is developed, and who participates in the community around it. This will set up the proper context for subsequent installments, which will focus on more specific topics.
Introduction
To most, Eclipse is an integrated development environment (IDE) for writing Java code. It is open-source and free for anyone to download. It provides everything a good IDE should have: an advanced Java source editor with incremental compilation, application debugging support, support for version control systems, and so on. In fact, over the past few years Eclipse has won numerous awards as the top Java IDE, including a Development Tool of the Year from developer.com. And its user base continues to expand.
Even if you are an Eclipse user, what you may not realize is that it is a lot more than just a Java IDE. Initially, Eclipse started as a tool integration platform. The original Eclipse developers recognized that there is a common set of infrastructure with a potential to be useful not just for a Java IDE, but other integrated development tools as well, regardless of their underlying programming languages. Indeed, today there are Eclipse-based IDEs for developing applications in C/C++, COBOL, PHP, Eiffel, Ruby, and others.
However, after a few initial releases, the developer community quickly realized the potential of using Eclipse technology in contexts other than software development. Its modular architecture and solid extension and customization strategy allowed anyone to create applications not originally anticipated by Eclipse developers. Thus, over the last few releases, Eclipse expanded its focus from being a tool integration platform to a full-fledged rich client platform (RCP). Its various components and frameworks have been refactored in a way that makes it possible to use Eclipse as the foundation for both IDE and non-IDE applications. Today, the list of companies building their products on Eclipse RCP is rapidly growing. Soon, you may find yourself using an Eclipse RCP application, whether you actually realize it or not.
So what exactly does Eclipse provide? What is its architecture? And who develops it? Take a look.
| What’s in the Name? |
|---|
| You may have heard a rumor that IBM selected the name Eclipse specifically to suggest that the new project would obscure, or eclipse, Sun Microsystems and its products. However, whenever you ask one of the original project founders, they’ll tell you that the name was selected because at the time, project names starting with an “e” were popular. The word “eclipse” sounded right and so it stuck. In fact, as you can tell from the recent press releases, Eclipse aims to be an industry unifier, rather than the opposite. |
Getting Started
The best way to learn about Eclipse is to download the Eclipse SDK, which provides everything necessary to write Java code and even develop Eclipse plugins—the fundamental building blocks of any Eclipse application. Later on, you will take a closer look at just what Eclipse plugins are. Before you start downloading the SDK, please make sure your system satisfies the minimum requirements (see the sidebar). The size of the download is approximately 100 MB.
| Minimum System Requirements |
|---|
|
The minimum system requirements of an Eclipse-based product actually depend on the kind and number of plugins that comprise it. Whereas the documentation does not explicitly state it, Eclipse SDK 3.1 will run on a Pentium-class machine with a minimum of 256 MB of RAM (the more, the better, of course; you may succeed with less, but I don’t recommend it for a good user experience). Another important pre-requisite that you must have before you can use Eclipse is a compatible Java Runtime Environment because the Eclipse SDK does not include one. Which specific JRE you should use depends on your hardware platform and operating system, but generally, you need a version 1.4 or later. See the Target Operating Environments section of the Eclipse Project 3.1 Plan for a list of Eclipse Reference Platforms (in other words, platform configurations on which Eclipse SDK 3.1 was explicitly tested and validated). |
To download a free copy of the Eclipse SDK, go to the Eclipse Web site at http://www.eclipse.org. The first page you will see aggregates several topics, such as the latest project news, community announcements, and articles. After clicking the downloads link on the left-hand side, you will get a page with links to everything that is available for download. The center column lists all the projects and subprojects; the right-hand column shows Featured and Top-10 downloads. To a newcomer, the sheer number of links may be overwhelming. Luckily, the one we’re currently interested in is displayed prominently in bold at the top—Eclipse SDK 3.1. The server makes the best guess as to what platform and operating system you’re using, based on the information provided by your browser. Click the link to see a list of Eclipse download mirrors, grouped according to the geographic region they serve. For shortest download times, find the one closest to you. Note that a mirror site may not have the particular file you’re trying to download, especially if it has been released only recently. If that is the case, choose the main download site. When you click the corresponding link, your download will begin. Extract the downloaded archive into an arbitrary location in your filesystem. It will create an eclipse directory with the contents of the entire Eclipse SDK. No other files need to be installed or configured.
Figure 1: Typical Eclipse SDK directory layout
Launching the eclipse executable (for example, eclipse.exe in Windows) from the eclipse directory will start the Workbench—the main Eclipse IDE window. First, you will be prompted for the location of your workspace, which is a directory where Eclipse stores your particular preferences, temporary files, and other application-specific data.
Figure 2: Eclipse SDK launch dialog
The dropdown remembers all workspace locations you have previously used with this particular installation. Specify an arbitrary path in your filesystem (for example, the default selection should be just fine) and click OK. The Eclipse Workbench will open up in the Java perspective—a set of views, menus, and toolbars that help you write Java code. On the right-hand side, you will see a Welcome view with information, links, and instructions on how to start using the application. I encourage you to explore the Workbench and especially the well-written and quite comprehensive on-line help, which will, among other things, walk you through creating a Java project. You will explore this particular topic in more detail in the next installment of this series.
More than IDE
After visiting the downloads page, you may have noticed that there is more to Eclipse than just the SDK. Instead of clicking the prominent Eclipse SDK 3.1 link, go to the Other downloads for 3.1 page and you will find that each release build consists of a rather large number of deliverables.
First, there is the SDK, which consists of the core platform, Java Development Tools (JDT), and the Plugin Development Environment (PDE). As I mentioned earlier, its purpose is to provide developers with all tools necessary to build Java applications as well as extend Eclipse itself. The ability to use Eclipse to extend itself (specifically provided by the PDE) is very powerful, and you will examine it in much more detail in a later installment of this series. Another way to look at the SDK is that it contains everything from the main Eclipse project (you will take a look at other projects shortly). You will notice that there is a separate downloadable archive file for each supported platform. In addition, there are also source build packages that can be used to build the SDK from scratch (with the provided instructions).
There are some deliverables that are not packaged with the SDK and must be downloaded separately, namely the documentation in PDF form (an on-line version is provided as part of Eclipse’s Help system); automated JUnit plugin tests, which can be used to verify the build (this is especially useful when building your own, customized distribution because all official distributions must already pass all unit tests before being published); the Release Engineering (releng) plugin, which aids in building customized releases; and finally the Example plugins, which serve as an excellent starting point for learning how to extend Eclipse. There’s also FTP and WebDAV support, which is only needed if you plan to use these services, so that too must be downloaded separately.
If you don’t need the entire SDK, you can download only a specific subset of it. There’s the RCP Runtime Binary, which can only be used as the target platform when developing RCP applications (more on that later), and the RCP SDK (same as the runtime binary, but with source code included). The Platform Runtime Library is the core “tool platform” and can be used as the foundation for your own Eclipse-based tools—it does not contain the Java Development Tools or the PDE. Again, the Platform SDK includes the corresponding source files. The JDT Runtime Library and SDK provide only the runtime binaries and binaries with sources, respectively, for Java Development Tools. Likewise, the PDE Runtime Library and SDK do the same for PDE. Lastly, there are platform-specific releases of the Standard Widget Toolkit (SWT), which can be used to build standalone applications that don’t need the entire Eclipse platform.
But what about all those “projects” listed on the downloads page? In fact, Eclipse consists of several projects, most of which have their own sub-projects. To learn more about them, you can click the projects link on the left-hand side. Generally, you will find that some of these projects have large corporate sponsors, while others are supported solely by individual volunteers and enthusiasts. Why and how these projects are structured the way they are should be clearer once you’ve read about the Eclipse platform architecture and the Eclipse community. For now, it’ll suffice to say that there is a formal project proposal process and anyone with a good idea, large or small, is encouraged to participate.
The main Eclipse Project delivers what you already know as the SDK—the core platform, Java Development Tools, and PDE. Formally, its mission is to realize the vision of Eclipse as an industry platform for integrated tools as well as rich client applications. As the oldest Eclipse project, and also delivering the components that Eclipse is best known for, its structure and development process serves as an example for other projects to follow.
The Tools Project oversees the development of a number of mature tool technologies that build upon the Eclipse platform. It consists of several sub-projects, each of which deserves not an article, but a book of its own, so I will not go into much detail here. They are the Visual Editor, GEF, EMF, UML2, C/C++ IDE, and COBOL. The Visual Editor project delivers a GUI builder framework for Eclipse. An included reference application can be used to rapidly develop SWT as well as Swing user interfaces. The framework’s ultimate goal is to provide the foundation for development of non-Eclipse GUIs. The Graphical Editing Framework (GEF) supports the creation of rich graphical editing tools, such as diagrams, graphs, figures, and other visual components. The Eclipse Modeling Framework (EMF) provides a powerful foundation and tools for creating application models. Its code generation tools support round-trip engineering, which eases code and model maintenance headaches while providing rapid application development capabilities. The UML2 project delivers an EMF-based UML2 meta-model, which can be used as a basis for developing UML modeling tools. The C/C++ and COBOL IDEs provide their respective equivalents of the Java Development Tools.
The Technology Project is a kind of incubator for new ideas, tools, and core platform enhancements. Its list of sub-projects is rapidly growing. After reaching a certain level of maturity, some projects “graduate” into the Tools Project or become part of the Platform itself. Others may be merged together as their concepts evolve. Currently, there are 19 approved sub-projects and nine proposals, so I won’t mention each separately. For their detailed descriptions, please visit the Technology Project home page.
The Web Tools Platform (WTP) Project aims to provide a standards-based platform for developing vendor-neutral Web application development tools. It is a relatively new project whose first release is widely anticipated. The project was jump-started by an initial contribution from IBM, most of which came from its WebSphere Studio product line. Its two sub-projects are the Web Standard Tools (WST), which focus on tooling for Web-based applications in general, and J2EE Standard Tools (JST), which specifically target J2EE application development.
The Test and Performance Tools Platform (TPTP) Project provides an open platform for the development of testing and performance tools. Its sub-projects are the Platform, Monitoring Tools, Testing Tools, and Tracing and Profiling Tools. What was initially IBM’s Hyades project is now a multi-vendor effort involving IBM, Intel, Compuware, CA, Scapa, SAP, Fokus, and OC Systems.
The Business and Intelligence Reporting Tools (BIRT) Project addresses the need for common reporting features in Java. Although it is also a fairly new project, it already has the first official release behind it. Currently, it provides an Eclipse-based Report Designer, Report Engine, and Chart Engine, and produces output in HTML and PDF.
The latest addition to the list of approved top-level projects is the Data Tools Platform Project (DTP). Its mission is to foster the creation of data-centric tools, frameworks, and applications, such as data source management consoles and browsers. It was established as a response to the community’s demand for these technologies.
This list will likely grow in the near future as new projects are proposed and approved. Additionally, there is a number of very useful open-source projects based on Eclipse that may be hosted elsewhere and are not formally a part of the Eclipse offering.
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.
Conclusion
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.
Resources
- Eclipse Web site: http://www.eclipse.org
- Planet Eclipse: http://www.planeteclipse.org
- Eclipse Plugin Central: http://www.eclipseplugincentral.com
- EclipsePlugins: http://eclipse-plugins.info
- Eclipse Zone: http://www.eclipsezone.com
- 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.
