Eclipse is the dominant Java IDE by all measures, especially in terms of adoption and the size of its plug-in ecosystem. It reached this prominence due to the decision of its original parent, IBM, to spin it off to a separate foundation, where Big Blue could fund its continued development and Eclipse could also draw the support of other vendors who might otherwise baulk at contributing to a vendor-owned product. This strategy has worked well, in part because it was well funded and because of the choice of management personnel, who have done an excellent job of reaching out to contributors, building a community, managing the progress of subprojects and avoiding controversy.

The importance of Eclipse's vendor independence was made clear earlier this week, when Google publicly announced that the IDE is its platform of choice for Android development. While Oracle's NetBeans might have once been a candidate for this recommendation and technology commitment, Oracle's recent suit against Google has conclusively precluded such a development. Politics matter in this marketplace, and Eclipse has always played this card adroitly.

What is missing from the Eclipse formula is superior technology. Eclipse has long been a middling Java IDE that many people use but few people love. It has improved steadily over the years, on the basis of annual releases that are carefully synchronised across major components and delivered to the market in the June timeframe. This year's release, version 3.6 codenamed Helios, adds several new features to Eclipse. I'll get into those shortly.

The design of Eclipse is unusual in several respects, all of which make it a sui generis IDE, with the result that knowledge of how other IDEs work has little carry-over value when using Eclipse. The core concept is that Eclipse runs using perspectives, which are different ways of representing the panels and layout of the IDE. These perspectives can at times be radically different depending on the activity. It's a design that caters to plug-in development, but at the cost of inconveniencing the user, who must cope with sometimes dramatically different layouts depending on what activity is being performed.

Within the basic Java development environment, Eclipse forgoes conventions and requires users to align with its vision. Before you can create projects, for example, you must first create a workspace. Within the workspace (a concept that has no counterpart in the other IDEs) you build projects. You can also create working sets, which are portions of the workspace grouped as if they were separate entities. This reliance on workspaces means that creating or migrating projects can be a tedious process, poorly supported by wizards with unusual and unexplained options. The concept of "just do it" does not exist in Eclipse. Almost everything requires filling out dialogs or choosing options that are either indistinguishable or unintuitive.

Eclipse IDE

Eclipse's Java coding perspective.

Consider, for example, a mixed Java and Groovy project imported into Eclipse without a Groovy plug-in. If you right-click on the Groovy file to edit it, a popup menu offers the following options: text editor, system editor, in-place editor or default editor. Because no help is available with this list, the right choice is a pure guess. Things go downhill from here: If you click on system editor, Eclipse tries to run the script rather than allowing you to edit it. In sum, most Eclipse users must trust their hard-won knowledge of its ins and outs, rather than navigating intuitively through its features.

To learn those ins and outs, users rely heavily on the help system, which has improved significantly over the years, although it still has gaps. In addition, the number of false error reports, which were a common bugaboo of early Eclipse dialog boxes, has been essentially eliminated. The IDE is definitely improving from release to release, but it needs what NetBeans received a few years ago: a rewrite and redesign of the core editing capabilities.

I should add that Eclipse's design is a problem primarily in the Java space, where it faces high quality competition, so that its drawbacks are more telling. In other areas, such as C development, where there are fewer good IDEs, Eclipse is popular and accepted without complaint. It is probably the principal IDE for C/C++ development for Linux, for example.

OUR VERDICT

Using Eclipse, one gets the feeling of nearly endless capability and tremendous scalability. The seeming unlimited capability is in good part due to the very wide range of plug-ins. This in turn is partly a result of the fact that most plug-in developers support Eclipse first. Many vendors never port their products to other platforms. Even very popular plug-ins, such as the excellent task manager Mylin, often are available only for Eclipse.

In the past, the management of plug-ins in Eclipse has been a problem for users, as one plug-in often depended on other plug-ins that had to be at certain version numbers. Eclipse has steadily addressed these issues. With this year's release of the Eclipse MarketPlace, it has also addressed the difficulty of finding a plug-in you might need.