have tried?quite hard at times?to rely on Eclipse as my main Java IDE, but I have been unable to because, simply stated, Eclipse hasn’t met the evolving needs of Java developers. And by Java developers, I don’t mean the minority who build Eclipse tools. I mean the majority who program in teams that deliver enterprise Java applications on the J2EE platform.

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.

My Java IDE History

I have tried many Java IDEs over the past 6 years. My first was Symantec Visual Café, which wasn’t pretty but it was one of the first to come with a debugger. Despite the fact that Visual Café had a debugger, it was clunky. Leading me to look out for alternatives. Eventually, I discovered Forte. It wasn’t perfect, but it was better than Visual Café. So, after a year of Café, I switched to Forte. Of course as Java evolved, Java Platform Debugger Architecture (JPDA) allowed every IDE to have a good debugger. Soon after, Sun took over Forte and forked it into a free, open source version called NetBeans and a commercial Forte product. That was when my team evaluated NetBeans and Eclipse, another open source Java IDE. At that time, we chose Eclipse because it was faster and it looked better than NetBeans.

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.

Requisite Technology Support Not Found

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 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 does provide syntax highlighting and rudimentary auto-completion for Ant build scripts, which are XML documents. But why implement such narrow XML support? Why hasn’t Eclipse provided syntax highlighting and DTD-based auto-completion for other XML documents? It’s quite strange really?especially considering that most of Eclipse’s own configuration files are XML!

On the plus side, Eclipse has almost completed work on tools that support exactly these technologies as part of its Web Tools Platform Project. While this is a commendable step in the right direction, one wonders what the Eclipse community was waiting for all this time.

Eclipse doesn’t even know what a Java Web application project is. It can handle only a simple Java project; it has no native support for any J2EE project type. So it always mistakes the “meta.inf” file for its own plug-in meta-inf. At the very least, Eclipse should be able to differentiate between a plug-in and a non-plug-in project. Beyond this, Eclipse provides no means of specifying inter-project packaging dependencies?essential for managing large, enterprise projects. Short of using Maven, it’s completely impossible to have J2EE modules in separate projects and declare a packaging dependency on them. For example, if you have a EAR project (which is simply a packaging project for its components) and an EJB project with two Web applications, how do you tell Eclipse to package the EJB and the Web apps in the EAR, as well as make the EJB available to both Web apps, without editing deployment descriptors and writing long, convoluted Ant scripts?

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.

[Author’s Note: For a $29.95 annual membership fee, the Eclipse plugin MyEclipse offers an end-to-end J2EE IDE for Web, CSS, JavaScript, J2EE, XML, JSP, struts, JSF, and application server integration.]

The Big Blue Burden and Looming Lock-in

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. For example, why did it take them until this past May to adopt Lomboz, the popular open source J2EE development environment? It’s been around for more than two years. This lag results in an IDE that offers no support for some key new technologies that have been integrated over time into the J2EE stack.

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.

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.

What Happened to Best Practices?

Eclipse, to my knowledge, also hasn’t done anything significant for promoting best practices in development since refactoring. Consider Ant integration as an example. Eclipse supports Ant?its right there on the tool bar?but the support ends at running Ant scripts. So, you ask, what more could one want? Well, Ant is the de-facto standard for Java build tools, yet Eclipse builds do not use Ant by default. They use project meta-data that are built and maintained by Eclipse itself. So, while Eclipse supports Ant and even allows a developer to configure ‘builders’, Ant is by default a second-class build tool. By contrast, NetBeans generates a project Ant script, providing the base for arranging your projects and their dependencies in a best practices manner.

UI Confusion

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…”?

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?

To be fair, the new Eclipse 3.1 shows signs of improved usability in some respects. However, it still has a long way to go for the UI to be intuitive, and the new Web Tools Platform Project (still in beta) is quickly adding new dimensions of complexity to the already confusing UI. Nonetheless, it’s a fair achievement for the slumbering Eclipse community. I will await its release before passing judgment.

A Functionally Handicapped IDE

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 new projects that (hopefully) will eventually become a part of Eclipse, such as the Web Tools Platform Project, will go a significant way in bridging the gap. One can only hope that the Eclipse community will continue to keep its eyes open and become more diligent in meeting our needs.

Tell us what you think! Weigh in on this issue in the ‘Talk to the Editors’ forum at http://forums.devx.com/showthread.php?p=431674.