On February 2nd, the Eclipse Board of Stewards announced their reformation as a not-for-profit trade association. This was the transition of Eclipse from an IBM-launched (and to some extent, -controlled) open source project to an independent body. During the three days that followed, the first EclipseCon was held in Anaheim, California. Six hundred developers attended sessions, participated in BoFs, and shared their experiences coding for this new platform.
The conference began with Erich Gamma and John Wiegand's keynote platform overview that they described as an appetizer for Eclipse 3.0. Erich is the Java Development Tools (JDT) lead for Eclipse and the EclipseCon Program Committee Chair. John is the Eclipse platform lead.
They began by explaining the roots of the Eclipse platform. In constructing a developer-friendly tool, they thought back to some of the best features from tools and other platforms they had worked on. Wiegand said that from Smalltalk they wanted to bring the ability to change anything at any time. Gamma added that they had learned about user configurability from Hoops. There they had learned how to do it, and almost as importantly, the dangers of overdoing it. Other experiences encouraged them to maintain an API focus and to think about the interesting functionality that an IDE can bring to big projects that may not apply to HelloWorld-sized projects. Add to all that the requirements from the micro-space of building up your tool one plug-in at a time, and you have the makings of what Gamma referred to as the evil plan to "focus on a stable foundation and make it fun to extend and hack."
You have seen this strategy before (think reusable, lightly coupled, small components), yet the Eclipse community seems well on the way to making it work. In fact, Eclipse is built around plug-ins. For a taste of how this works, check out the two chapters from Erich Gamma and Kent Beck's book Contributing to Eclipse we reprinted on java.net. In Eclipse, there is a small microkernel, and everything else is layered on top as a plug-in. The community is encouraged to use, create, and publish new plug-ins. This makes the platform more attractive, and so this increase in quality plug-ins helps to grow, advertise, and support the community.
Gamma referred to the downside in quoting feedback from the ServerSide that "the space is flooded with inferior plug-ins." As Wiegand later pointed out, there are two distinct issues here: the large number of available plug-ins and the large number of installed plug-ins. The first issue is being addressed by newly created community repositories of plug-ins at eclipseplugincentral.com and eclipse-plugins.2y.net. To address the second issue, the 3.0 release adds a filtering feature for hiding some of the installed plug-ins that are not necessary for users engaged in "activities," as Eclipse calls them.
In 3.0, the goals were to mature the platform, enhance the IDE, and to push down functionality. This last point is in response to those who would like to take some of the functionality from the JDT and present it in their own plug-ins. Gamma explained that they have worked from the concrete to the abstract. As they have pieces working in the JDT, they can better see how to open up the platform and allow others access to features that they have added to the JDT.
The 3.0 release will introduce Swing/SWT interoperability, but initially this will only be supported on some platforms. The Eclipse team explained that the SWT architecture renders user interfaces by calling on the underlying operating platform to paint widgets. Swing emulates interfaces by painting widgets bit by bit. Successful SWT/Swing integration, demonstrated at EclipseCon running on Windows, requires platform-specific code written by the Eclipse team. On Windows, this means that existing Swing components can be reused and will talk across a bridge to the SWT components in the same application. Eclipse 3.0 will have a product-quality version available for Windows and an early access for Linux. This feature is not yet supported in any way on other platforms.
These SWT issues matter for those looking at Eclipse as a Rich Client Platform (RCP). In addition to being a platform for tools and developer-centric releases, Eclipse is now being thought of as a platform for end-user applications. Gamma demonstrated a calculator where a minimal set of plug-ins could be loaded. As an example, he showed the loading and unloading of a multiply button. In 3.0, you'll see that the generic workbench APIs remain in the
org.eclipse.ui package, while the IDE-specific APIs are now in
org.eclipse.ui.ide. The runtime has also been replaced with one compatible with the OSGi architecture.
In general, the changes in 3.0 are designed to minimize the changes necessary for end users while moving forward, developers may be required to make changes in their code. In other words, the goal was that most 2.x-API-compliant plug-ins should just continue to work — there should be binary compatibility from 2.x to 3.0. Gamma and Wiegand encouraged the audience to test their plug-ins and file bugs for those that don't just work. For source, you should use the porting guide and also take advantage of the migration tools available in the Plug-in Development Environment (PDE). Gamma ended by characterizing the theme of 3.0 as "opening the door."
Much of Michael Tiemann's Wednesday keynote came from Malcolm Gladwell's book The Tipping Point. In particular, RedHat CEO Tiemann spoke of "connectors, mavens, and salesmen." Connectors know many people. They may not know them deeply, but they know them enough to make a phone call and to bring people together. Where people tend to function in communities limited by about 150 people at the most, connectors make it easier to bridge communities and to help spread an idea. Mavens are idea brokers. They like learning things, knowing things, and explaining what they know to others. Mavens provide the message, and connectors spread it. The third category, salesmen, are there to persuade the unconvinced. In Tiemann's view, Eclipse is at a tipping point. Enough mavens are sold on the technology, and key connectors have begun to link communities. In addition, some of the creators of plug-ins and users of the platform are evangelizing Eclipse like salesmen.
Tiemann then turned his attention to open source developers, Java, and Eclipse. He described open source developers as pragmatic folks who won't use proprietary languages, tools, or libraries. Tiemann used a politically charged phrase, "Java Apartheid," to characterize the Java community as being one that says, "To join our community, you have to reject others." On the one hand, he argued that few people commit to a single platform and say "I'm going to run exclusively this." On the other hand, he predicted that within three years Eclipse will be an academic standard.
Tiemann said that "the open source community has felt rejected by Java, and Eclipse is changing that." In response to an audience question, he said that NetBeans is like a comfy padded cell while Eclipse is more inclusive. He concluded that "Eclipse will provide a home in the open source community for Java developers."
We were able to talk to Eclipse spokesperson Skip McGaughey, Instantiations CEO Michael Taylor, and John Wiegand about what has changed with the newly formed Eclipse foundation. McGaughey stressed that what hasn't changed is equally as important. Although the organization's governance has changed, the code base is stable and remains royalty-free. What gets done has not really changed. The new governance allows more work to be done in committees. As the member companies grew from nine to 60, it became too unwieldy to make decisions with that many people around a table.
Eclipse maintains its focus on being by and for technology people. The roadmap is still created in public, both from the bottom up and from the top down. Although IBM's WebSphere is built on top of the Eclipse platform, there is now a variety of companies building on the same codebase; following the roadmap becomes essential for companies to synchronize plans. Taylor added that IBM's willingness to let go of controlling Eclipse shows a lot of confidence and faith that they can still build WebSphere on top of a platform that is evolved by the community. He said, "The Eclipse platform is bigger than IBM in the same way that Java is bigger than Sun."
In response to questions about Sun's open letter to Eclipse, McGaughey answered that "We see that Sun has contributed immensely to the community with their work on Java." He explained that Eclipse had worked closely with Sun while working on the foundation bylaws and membership agreement and that Sun had added value with suggestions, many of which were adopted. McGaughey made it clear, however, that the basis of membership in Eclipse is that every company signs the same agreement. There are no bilateral agreements. He said that Sun is able to join just like IBM, Intel, and others.
McGaughey said that there is no requirement that any member give up any technology; the only requirement is that they will use Eclipse in at least one commercial offering. Thus far, all member companies have agreed to that condition. As to when or whether Sun may join Eclipse, McGaughey stressed that it is fundamental to the process of companies joining Eclipse that they are allowed to make their decisions privately. Even when a company joins Eclipse, they are able to choose when they make the announcement, and the details remain private.
As Eclipse expands the C tools, more support for C# and .NET development could be built on top of the platform. McGaughey said that "Eclipse is multivendor. One of those vendors could be Microsoft. Open is open."
The Eclipse identity is intended to be driven by tool developers. It is designed to be a platform for extensiblity. Much of the foundation's work is to foster and support an ecosystem around this platform. John Wiegand acknowledges the recent developer interest in the Rich Client Platform (RCP) applications, but maintains that the predominant focus remains building a tooling platform. McGaughey said they were surprised by the interest in RCP.
Taylor countered that for his company, Eclipse remains a tool-innovation platform. He has built tools that sit on top of other IDEs, and has now bet his business on Eclipse as an interoperability platform. He was asked if he is concerned that Eclipse reinforces developer expectation of high-quality tools for free. He agreed that "we're training the world that they can get pretty good tools for free. It means that we have to do things way better than you can get for free."
McGaughey returned to the question of RCP: "When Rich Client came out, it was outside the scope." Wiegand said that several individuals built Rich Client applications and "told us if you make changes like this, we will be able to do more of this." He said that while the Eclipse APIs leverages SWT, the community wants to be able leverage existing Swing components. As noted above, Swing-SWT interoperability is making its limited debut in 3.0, and Wiegand encourages ongoing community testing of this bridge.
"The language problem is hard," McGaughey said. "This will be solved when customers start to drive technical solutions and push for Eclipse and Sun to be engaged. Multiple companies have huge investments in Swing-based visualizations, but want to use Eclipse." Taylor said that "both native and the emulated approach need to be supported. These battles never have a winner. If the JCP is the right standards body, then maybe SWT should become a specification request." McGaughey agreed that there is a need for standardization and perhaps the JCP or another standards body would be an appropriate solution.
In some ways, Eclipse and SWT are continuing on the same path as Java, but at the next level of abstraction. When Java was introduced, the language and libraries weren't as threatening as the runtime. Now Java developers could write to the Java standard and, at least in theory, not to the operating system. Now Eclipse slides in on top of the JVM and clearly describes itself as a platform for which developers can write plug-ins. You can see why the Sun's open letter to Eclipse described the issues between the two sides as being business and political, and not technical.
The analogies to the current U.S. presidential race seem compelling. In exit polls and interviews, people voting in Democratic primaries and caucuses say that it is more important to them to nominate a candidate that can win for the Democrats in the fall than which of the top few candidates they choose. Although Eclipse is more than just a tool for Java development, in the Java tools race, Eclipse seems to be the tool of choice because it has a chance against that other platform.
Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.