There is an article over at DevX entitled “Opinion: Eclipse Fails to Meet the Enterprise Java Developer’s Needs” by Gerard Fernandes. As the name suggests, the author attempts to make the argument that Eclipse is just a fundamentally bad piece of software. Unfortunately, in attempting to do so he makes some factual errors.

I am not affiliated with the Eclipse project in any way other than as a satisfied user. I have been using Eclipse since about 2003 and I am very happy with the tool. Before that I used NetBeans, Sun Forte for Java and JBuilder going back to about 2000. Before that I used Emacs or some other text editor for my Java coding. While I am not an Eclipse “expert” (whatever that means) I have watched the product evolve and have been amazed at the pace of progress. I mention all of this so that my biases are known and understood from the beginning. Now, on to the article.

I think that the main thrust of the article is summed up nicely in the second paragraph:

When Eclipse was first introduced, it was lauded for introducing not just an IDE but also features that promoted good development practices. Key among these were on-the-fly compilation, a stricter compiler, and most importantly, refactoring. Since then, the Eclipse community has rested on its laurels and done nothing significant to improve the IDE. Eclipse has failed to see the architectural directions that Java application development has taken. In doing so, it has let down the many Java developers who use it.

Resting on its laurels? Eclipse is a very big organization encompassing a large number of projects. Even if we restrict ourselves to just the core IDE, there has been quite a bit of activity since Eclipse was announced in 2000. Check out the Eclipse New and Noteworthy section for the recent 3.1 release. Make sure you click “Next” at the bottom of each page; there are 7 pages total. That is a lot of “new and noteworthy” changes for an IDE that is “resting on its laurels”! I am willing to concede the point that the 3.1 release does not contain any ground-breaking or “innovative” features like incremental compilation or refactoring. But really, how many “innovative” features can a single product have?

Over time, as our focus rested almost completely on Web applications and we increasingly relied on XML technologies, Eclipse became more and more difficult to use. Its Ant integration was never straightforward; its concept of perspectives confused many of us; and synchronization bugs did not help.

Meanwhile, with each new version, NetBeans got better editors with more support for XML technologies. None of these were available in Eclipse, which made integrating anything XML into a J2EE project a pain. So we eventually switched from Eclipse to NetBeans. NetBeans was slower at that time, but the performance deficit was more than offset by the productivity gains that better XML support provided. And with the JDK 1.3 release, even the performance problem went away. In 2002, we standardized on NetBeans for all Java projects.

This paragraph is the spearhead of the author’s complaints. It appears that he is complaining about Eclipse as it existed in 2002. Needless to say, most of these issues have been addressed in the intervening 3 years. The author doesn’t give much indication that he has spent any significant time using Eclipse since then. In fact, the author’s main beef with Eclipse seems to be that Eclipse in 2002 did not have features that NetBeans has today. This is also not the last time that he complains about Eclipse being confusing. More on that later.

So what does today’s Java developer need from an IDE? Considering that Java thrives in the middleware arena, an IDE must support a lot of technologies for a typical enterprise Java application. XML, XSL, XML schemas, SOAP WSDLs, JSPs, and JSP tag libraries are just some. Java provides the “glue” for bringing these technologies together in most enterprise applications that need to be available on the Web, over WAP, and over media other than traditional native software.

This illustrates a significant problem with the author’s arguments. He assumes that all Java developers have exactly the same needs from an IDE that he does. This is not only wrong, it hilights one of Eclipse’s greatest strengths: flexibility. The core Eclipse IDE does basic Java very well. If you have special needs then there are hundreds of plugins available and chances are that one of them fits your needs.

This brings up Eclipse’s first — and perhaps biggest — failing. Eclipse has not supported any of these technologies. Eclipse currently doesn’t understand JSPs, or XML, or XSL, or XML schemas. At a time when these technologies are core to J2EE and when Java is predominant in the distributed enterprise application arena, Eclipse inexplicably remains focused on desktop Java applications.

Eclipse has supported various XML technologies via plugins for some time. To say outright that Eclipse does not support any of these technologies is just wrong. I looked at eclipse-plugins.info and found 33 plugins in the XML category. One plugin, XML Buddy, has been around since about 2002. There are also full featured J2EE plugins that cover most, if not all, of the J2EE development lifecycle, like Exadel Studio, Lomboz, MyEclipse and the Eclipse Web Tools Platform project (see The Story of Web Tools Platform). Of course, IBM also offers Rational Application Developer which has a full toolset for J2EE development.

Bizarrely, Mr. Fernandes mentions no fewer than four Eclipse based J2EE development tools that presumably provide the functionality he needs, but does not explain why he is not happy with them.

Of course, those promoting Eclipse would like you to believe that you can write your own plug-in if you need functionality that Eclipse doesn’t offer natively. And you quite rightly could — in quite the same way that you could write your own OS if you wanted to. I wonder how many car manufacturers would survive if they told their customers to make their own fuel injection systems if they didn’t like the carburetors that came with their cars. Perhaps we are all fortunate that Eclipse doesn’t make cars.

This is absolute nonsense. One way to “cheat” when arguing is to misrepresent your opponent’s arguments in the most absurd way possible. That appears to be what is happening here. No one is suggesting that everyday Eclipse users run out and write plugins for every piece of missing functionality. For one thing, its simply not necessary. There is already a significant number of plugins available for Eclipse and the number grows every day.

One need only notice the number of IBM email IDs on the Eclipse bug-lists to realize that the Eclipse community has been — and continues to be — dominated by a certain corporate entity with strong leanings towards the color blue. I believe this has led the Eclipse community to drag its feet when creating tools for building today’s Java applications…

The IBM influence is indicative of Eclipse’s most significant problem: it is a “platform” for some large corporate entities, which use it to further their tool-sets and therefore lock developers into one development platform. If anyone wants proof of this, they need look no further than IBM’s WebSphere Studio Application Developer (WSAD), which while based completely on the Eclipse core, provides many tools for building enterprise Java applications on the WebSphere application server.

This is the old ‘IBM Controls Eclipse’ canard that gets trotted out by the NetBeans people constantly. Mike Milinkovich, Executive Director of the Eclipse Foundation, deals with this issue here and here.

According to Mr Milinkovich:

I would have thought that having IBM competitors like BEA, Borland and Computer Associates would have put this to bed. Each of these companies are investing $250,000 per year and eight developers into Eclipse. Why would they possibly do that if Eclipse was IBM controlled? Believe me, those companies did their homework before they made those kids of investment decisions.

BTW —- here are some numbers that you may find interesting. Since September 2004, the number of Eclipse committers who work for IBM dropped from 79% to 58%. And the percentage of top-level projects led by IBM employees dropped from 66% to 33%. And based on the new proposals that we already have in process, that will soon drop further to 22%, along with the total IBM committer ratio dropping below 50%. (I wonder what the equivalent numbers are at NetBeans?)

I don’t think there is much I can add to that. Now, let’s put this little trope to bed and move on, shall we?

Back to Mr. Fernandes:

That puts Eclipse on par with stripped-down, “free” versions of any other commercial IDE that attempts to lock developers in to a specific development/deployment environment. The biggest advantage of the J2EE specification is that an enterprise Java application can be put to work in any J2EE-compliant application server. Getting locked into a J2EE application server eliminates that advantage.

This is another bizarre argument. How can you “lock” developers into an IDE? Application servers have proprietary APIs and custom descriptor formats. It is easy to see how this can lock you into a particular product. However, the code that a developer writes is not tied to the IDE they use. The IDE may generate descriptors and code for you, but that still does not lock a developer into that IDE. This is another bad analogy used to bolster a weak argument.

If you love visual obfuscation, Eclipse is for you. The resource view is never really synchronized with the file system. This makes the many perspectives that come with Eclipse quite confusing, particularly the CVS and synchronization perspectives. Why can’t Eclipse show what really exists in the file system rather than throwing up strange errors about “resource not synchronized… refresh and try again…”?

This is further evidence that Mr. Fernandes hasn’t used Eclipse recently. Eclipse now has an option to automatically refresh the workspace.

Everyone promoting Eclipse defends its very unintuitive UI, saying “You get used to it.” Any GUI that needs getting used to is a poor user interface. GUIs are meant to be intuitive, or we might as well be programming in VI or EMACS on a text console. And ever wonder why Eclipse uses “Ctrl-H” for searching when everyone else uses “Ctrl-F”, or “Ctrl-L” instead of “Ctrl-G” to go to a line-number? Is it really necessary to introduce new keyboard shortcuts for common tasks?

First, Eclipse does use Ctrl-F for “Find”. It uses Ctrl-H for “Search”, which searches across multiple files. For the record, NetBeans uses Ctrl-P for the same functionality, which is usually reserved for “Print”.

Second, lets be honest here, all IDEs require getting used to, which is why people tend to be slow to switch. I have always found NetBeans to be confusing, but not everyone shares that opinion. That is OK, but lets not use that as an excuse to sling mud at the other guys.

Finally, I also have a problem with people who suggest that any software is “intuitive”. Using a computer is not an intuitive activity overall. According to answers.com, intuitive means “obtained through intuition rather than from reasoning or observation”. What in the human intuition guides us when creating Java source code? Ultimately, I find this argument to be a cover for “I found the software difficult to use.” That is fine, but saying that software isn’t intuitive seems to imply that everyone who uses it will find it difficult to use, which is clearly not the case.

So where does that leave Eclipse in a Java development shop that builds enterprise applications and Web services and performs XML-based configuration and data integration? It leaves Eclipse as a functionally handicapped IDE that offers far less than open source competitor NetBeans. At the end of the day, a good Java IDE must provide a lot more than basic project organization, poor source control integration, Java file compilation, auto-completion, re-factoring, and half-baked integration to Ant.

The statement that Eclipse has “poor source control integration” is laughable. Eclipse has the best source control integration of any IDE I have seen. NetBeans is nowhere even close. For example, Eclipse has native support for CVS and plugins that support Subversion, VSS, Perforce, ClearCase and many others. Eclipse has an awesome Team Synchronize view that shows you what files have changed on your machine and what files have changed on the server. Using tags and branches in Eclipse is also very easy.

The “half-baked integration to Ant” comment is also irksome. The author is essentially complaining that Eclipse does not use Ant as it’s build system like NetBeans does. However, Eclipse has excellent support for Ant, including a nice editor and a debugger.

To be honest, I had a problem identifying the author’s problem with Eclipse. He complains of lack of J2EE support, and then points out 4 tools that provide it. This feels like a NetBeans partisan doing a hatchet job on the opposition. There are so many factual errors about the actual functionality of Eclipse that I find it hard to see this article as anything but a troll. The presence of a few ad hominem attacks on Eclipse only serves to support this view.

As a side note, I find the ad hominem attacks very distasteful. I think that there is a legitimate conversation to be had concerning Java IDEs and how they compare. There is no need to resort to insults or misrepresenting the products. We are talking about tools here and not religion or politics.

Tags: eclipse, ide, java, myths, netbeans