Opinion: Eclipse Fails to Meet the Enterprise Java Developer's Needs : Page 2

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.

Eclipse's most significant problem: it is a "platform" for some large corporate entities.

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..."?

Any GUI that needs getting used to is a poor user interface.

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.

Previous Page