have triedquite hard at timesto 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.
|As we increasingly relied on XML technologies, Eclipse became more and more difficult to use.|
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 firstand perhaps biggestfailing. 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 reallyespecially considering that most of Eclipse's own configuration files are XML!
|Eclipse inexplicably remains focused on desktop Java applications.|
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 dependenciesessential 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 couldin 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.
|Editor's Note: DevX is pleased to consider rebuttals and related commentaries in response to any published opinion. Publication is considered on a case-by-case basis. Please email the editor at firstname.lastname@example.org for more information.|