Get a comprehensive comparison of the latest versions of the major IDEs in the Java development space: NetBeans, Eclipse/MyEclipse, and IntelliJ IDEA. Find out how well each performs in four common areas of development: Swing, JSP/Struts, JavaServer Faces, and J2EE/EJB 3.0.
ver since Eclipse burst out on the Java scene a few years ago, things have gotten very interesting for Java developers. With SWT and Swing toolkits both having their own strengths and weaknesses but none having any noticeable lead over the others in terms of pure performance or look-and-feel, Eclipse focused the competition among Java IDEs where it belongs: features, ease of use, and productivity. This article explores what the past few years of fierce competition within the Java IDE space (and of course indirectly with Microsoft Visual Studio.NET) have delivered.
It reviews the three major Java IDEs—NetBeans, IntelliJ IDEA, and Eclipse—from the viewpoint of basic, common features (installation, performance, editor, etc.), but it really focuses more on their strengths in four common areas of development: Swing, JSP/Struts, JavaServer Faces (JSF), and J2EE/EJB 3.0. Wherever possible, it also evaluates JPA (Java Persistence API) support, instead of hard-coded JDBC queries or particular libraries (such as Hibernate or Oracle TopLink).
Out of the three IDEs, Eclipse is the only one that exists in multiple versions/distributions, starting from the base distribution to pre-packaged ones with extra open-source plugins (such as EasyEclipse) and open-source/commercial hybrids such as Genuitec's MyEclipse. In order to provide a fairly realistic review of what Eclipse is capable of, I focused on the base distribution (including default Eclipse sub-projects such as the Visual Editor and Web Tools Project). Wherever I felt it was lacking, I also considered what MyEclipse offers as a commercial alternative. Frankly, at a subscription price of $49/year, I'd be hard pressed to find any commercial IDE with the functionality that MyEclipse provides.
Up first, though, is NetBeans 5.5.
| Author's Note: As an employee of Compuware Canada, I use the Eclipse-based, Model-Driven Java development tool Compuware OptimalJ. However, I have made every effort to ensure a fair review for each IDE, with no preferences to Eclipse. |
NetBeans 5.5
| Vendor: | Sun Microsystems |
| Website: | www.netbeans.org |
| Price: | Free/Open source |
| Distribution: | Base + Enterprise Pack + Visual Web Pack |
Installation
NetBeans 5.5, as well as its additional packs (e.g., Enterprise Pack with UML/BPEL/SOA and Visual Web Pack for JSF Development), is available as both ZIP downloads as well as cross-platform InstallShield installers. Under Windows, the installer integrates seamlessly into the OS, including registering the proper desktop shortcuts and adding an uninstaller in the Add/Remove Programs panel. Under Linux, it simply installs into the specified directory and creates a startup icon on the GNOME or KDE desktop. Unfortunately, it does not come packaged as an RPM or a .deb file, nor does it offer a standard repository, which would allow Linux users to install it as they do any other application.
General Features
At one time, NetBeans was synonymous with everything that was wrong with Swing: slow, bloated, ugly, and just plain unpleasant to work with. However, the NetBeans team has performed a massive overhaul of the entire IDE starting with version 5, and the combination of NetBeans 5.5 and JDK 1.6 provides arguably a top-notch user experience, in particular under Windows (Linux still has some UI glitches that are supposed to be addressed in NetBeans 6.0. In particular, version 5.5 lacks native GTK look and feel support).
The windowing system is about as advanced and flexible as one could imagine, with the ability to dock/hide/swap nearly any panel/editor in any possible configuration with great ease. I also found the menu layout very logical and easy to use, with all the most common functions being easily accessible (e.g., maintaining user libraries). All the while, overall stability and performance were excellent.
The basic Java editor is decent though definitely not the best in the field (in particular, code completion is somewhat slower than its competitors), but it is very workable. A basic set of refactoring functionality is also provided (in particular, the most commonly used rename/move features), although in my testing I found it often somewhat dangerous to use because it is not always context-aware. For example, renaming the package of an Action class in a Struts project does not update the corresponding entry in struts-config.xml (although it worked fine for refactoring JSF backing beans and updating their entries in faces-config.xml, as well as J2EE 1.4 sessions beans and their entries in ejb-jar.xml).
Swing Development
NetBeans's crown jewel is its famous new Matisse GUI designer, based upon the new GroupLayout layout manager, which originally was developed by the NetBeans team itself as an extension prior to being included in the base JDK. The combination of baseline support (i.e., the ability of controls to align automatically based on the position of the actual text within a control) makes creating professional looking UIs very easy. In fact, the powerful resizing and anchoring functionality make this the best UI designer I have seen for any language on any platform.
After installing version 5.5, I also grabbed the latest set of updates that were back ported to 5.5 from the newer 6.0 builds. These included some very productive features, such as automatic internationalization (with control per each form/dialog/panel as to which ResourceBundle contains all the internationalized strings), as well as the ability to use custom forms/panels (as long as they have been compiled at least once within your project). Matisse is a fine example of what the NetBeans team can do when they are at their best. (See Figure 1 for a sample of Matisse in action.)
| Figure 1. Matisse with Custom JPanel Components |
For Swing developers, an additional benefit of using NetBeans is the ability to use its very powerful RCP (Rich Client Platform) wizards for creating new, sophisticated Swing applications. In light of the popularity of Eclipse's SWT-based RCP, the NetBeans team has gone to great lengths to provide a viable Swing-based alternative and, dare I say, with impressive results (although the initial learning curve might be a bit steep for smaller projects).
JSP/Struts Development
NetBeans comes with a good JSP editor with all the basic features that one would expect and all the basic wizards and plumbing to start a new Struts project. The inclusion of an embedded Tomcat container makes developing and testing JSP apps particularly easy and fast. (Figure 2 shows the NetBeans web application wizard.)
| Figure 2. NetBeans Web Application Wizard |
The NetBeans web application wizard automatically configures web.xml and struts-config.xml and enables adding Tiles and Validator support. However, beyond that the only support it provides are some context menu options in struts-config.xml and wizards to add ActionForms, Actions, and Forwards. It offered no visual editors to show the page navigation within the application and provided absolutely no additional support for configuring Tiles and Validators (outside of creating the original configuration files and including the required libraries).
Personally, I found Struts support in 5.5 quite decent but definitely not as polished as what Matisse delivers. Also, no visual editor for JSP or HTML pages is available (not an issue for power coders, but a nice feature for more junior programmers). The lack of proper embedded JavaScript support for JSP editors along with only a basic CSS editor (though much better if the Visual Web Pack is installed) are areas that could use some improvements as well. (See Figure 3 for a sample of NetBeans's Struts support.)
| Figure 3. Struts Support in NetBeans |
JavaServer Faces Development
The NetBeans JSF support is pretty much identical to its Struts support. It provides a wizard to get a basic project started, includes the libraries, configures all the required files, and even provides code completion for backing beans' properties in the JSP editor, as well as a few wizards for navigation rules in faces-config.xml. No support for Apache MyFaces is available (only JSF RI), so the initial project setup has to be hacked by hand to swap out the JSF RI and use MyFaces.
No visual editors are provided whatsoever to maintain the faces-config.xml file. Everything is pretty much done through raw XML editing or the two or three basic context menu wizards. While this is workable and definitely sufficient for power coders, it hardly achieves the ease of use or productivity that other IDEs deliver for JSF developers.
However, the NetBeans Visual WebPack offers an alternate solution for building JSF applications by porting most of the features from Sun Java Studio Creator directly into NetBeans. This includes a Matisse-style GUI builder for web pages, with a rich set of JSF controls (recently open-sourced as Project Woodstock) that extend the basic JSF RI set, as well as support for data binding (both directly against database queries and even via JPA/Hibernate).
Despite all of these first-class features, the Visual Web Pack has a few drawbacks that might stop many Java shops from using it, namely:
- It lacks support for page templates (although you can save a Page as a template and use it as a base for new bases, but obviously changes to it do not cascade down). Support for either Facelets or the Tiles support from MyFaces would be of great use here.
- It lacks support for Apache MyFaces (potentially an issue when deploying to app servers that use MyFaces RI instead of Sun's implementation, such as JBoss).
- It has inflexible auto-generation of backing beans (which basically mimic the structural context of each JSF page in a straight ASP.NET fashion, making it unusable with conversation-oriented backing beans such as the ones required by JBoss Seam).
A great-to-have feature would be support for Facelets, which many in the JSF community are pushing as the total replacement for JSP (in particular, the JBoss Seam team has openly campaigned for it in all of its documentation).
Though if the NetBeans team addresses these deficiencies in the next release, I can't imagine any tool being as productive as the Visual Web Pack for JSF development.
Enterprise Development
NetBeans 5.5 was the first IDE to offer support for JPA and EJB 3.0, and it delivered quite well in this area. In particular, the auto-generation of JPA entity classes with annotations (including proper setup of the persistence.xml file, even with basic connection information) has saved me countless hours of boring, repetitive hand coding. The auto-generated JPA code is very high quality and instantly usable. Frankly speaking, developing a Swing app with Matisse and querying/updating a database via JPA was the first time my productivity has reached the level I worked at in PowerBuilder many years ago (which I still remember as the most productive client/server UI development tool ever, even though it had more than its share of imperfections).
For pure enterprise development, NetBeans offers both top-notch J2EE 1.4 and Java EE 5 support. In particular, for J2EE 1.4 projects, the EJB wizards take care of generating all the required code (including the business/home/remote interfaces, as well as their stub implementations—not to mention wiring the ejb-jar.xml configuration file). In short, NetBeans takes care of most of the verbosity related to J2EE 1.4 and provides polished out-of-the-box support for Java EE 5 as well (the first IDE to do so, although IDEA followed quite quickly).
On the down side, NetBeans offers official support only for deploying enterprise applications to GlassFish/Sun Application Server and JBoss. Nonetheless, the update site offers additional plugins for WebLogic and WebSphere, although I am not sure if the NetBeans team officially supports them.
The free Enterprise packs also add powerful UML diagram features (including two-way editing and synchronization with Java code), as well as BPEL/SOA editors. However, evaluating these was outside the scope of this review.
Suggestion to NetBeans
I really like NetBeans. Its underdog team came out fighting from a position where everyone thought Eclipse would eat it alive, and it has delivered some amazing features in its latest release (and much more to come in NetBeans 6.0). However, it simply does not have the same size community that Eclipse does. This starts to detract from the product when it comes to features that it does not offer out of the box (e.g., Google Web Toolkit, JBoss Seam, Jasper Reports, Spring, Tapestry, XDoclet, Echo2, Apache MyFaces, etc).
One of the smart things IBM did early on with Eclipse was give up control and create an Eclipse foundation, which has attracted a lot of third-party developers. Maybe it's time Sun gave up its iron grip on NetBeans as well and created an equivalent NetBeans Foundation. Eclipse has no technical advantage whatsoever over NetBeans at this point (frankly speaking, I think NetBeans looks more like a native Windows application than Eclipse does, despite the whole Swing vs. SWT debate). NetBeans simply needs more resources behind it to become number one in the Java IDE space, and I don't think Sun can make that happen on its own.
IntelliJ IDEA 6.0.4
| Vendor: | JetBrains |
| Website: | www.jetbrains.com/idea |
| Price: | $499.00 ($299.00 upgrade) |
Installation
Under Windows, IDEA provides a regular EXE installer. Under Linux, the installation is much more Spartan, consisting of a single TAR.GZ file. Upon extracting the contents, you have to manually change to the "bin" subdirectory and execute "./idea.sh". It fails if you do not have the $JDK_HOME variable set up correctly, preferably in your .bashrc file as follows, for example:
JDK_HOME=/home/jacek/Dev/Java/JDK/jdk1.6.0_01
export JDK_HOME
JAVA_HOME=/home/jacek/Dev/Java/JDK/jdk1.6.0_01
export JAVA_HOME
export PATH=$JAVA_HOME/bin:$PATH
Unfortunately, JetBrains does not provide a standard .deb or RPM file for any of the major Linux distributions. Therefore, the installation does not integrate into the desktop very well (e.g., no desktop shortcuts or K Menu entries are created). Worse, double clicking on the "bin/idea.sh" file from the Konqueror file manager did not work either (it was returning an error about JAVA_HOME not being set up, even though it was actually set up correctly). The only option that seemed to work was to drop to command line and execute "./idea.sh" manually. The IDEA installation experience under Linux needs some serious polish. It was the weakest of the three tested IDEs.
General Features
Just like NetBeans, IDEA comes with a very flexible layout, providing the ability to dock/pin/float panels in a variety of configurations. However, it didn't seem quite as smooth and configurable as the NetBeans windowing system (which IMHO is the one to beat).
However, this is a minor gripe in light of the outstanding IDEA editor, which has long been regarded as its crown jewel. The editor is fast, with complex context-sensitive color highlighting, hints, and suggestion pop-ups—not to mention an impressive array of refactoring options. The IDEA editor is any hardcore coder's dream. The more time I spent in it, the more little touches I found that made programming that much more efficient. I'm sure I barely explored all of its functionality during the limited time I had for reviewing. (See Figure 4 for a sample of IDEA's editor and its advanced coloring/syntax highlighting.)
| Figure 4. IDEA Editor in Action |
Swing Development
IDEA provides a fairly powerful GUI editor. It doesn't quite live up to NetBeans Matisse's, but it arguably is the next best thing. In particular, its support for JGoodies Forms (arguably the best layout manager available prior to GroupLayout) places it well ahead of those that are still stuck on GridBagLayout (like Eclipse's Visual Editor).
Interestingly, IDEA keeps the generated UI layout in a separate ".form" file (similar to NetBeans), but it does not generate the corresponding Swing code by default. It gets generated only during compilation via a proprietary GUI compiler (which can also be packaged as a separate Ant task). If you prefer to have the IDE-generated code directly in your .java file, you have to enable it via an option (which in my opinion is the preferable approach, since I would prefer not to have all of my UI code hidden and available only after running a IDE-specific code-generation mechanism).
JSP/Struts Development
Struts support in IDEA is nothing short of outstanding. In a fine example of the sort of attention to detail that IDEA is known for, it can even download all the required Struts libraries for you! Not only does it automatically set up all the configuration files (including Tiles and Validator), but it also provides a dedicated Struts panel called simply Struts Assistant, which provides graphical editors and productivity wizards for all Struts configuration files, including tiles-config.xml and validation.xml.
IDEA has no visual editor for JSP/HTML pages, but the regular IDEA JSP/HTML editor is superb even without a visual component. The support for embedded JavaScript (with full code completion!) especially will be a godsend to anyone dealing with large amounts of DHTML or AJAX code. As another example of the type of attention to detail others can only dream of, the JavaScript editor comes with support for browser-specific elements (IE, Mozilla, and Opera), as well as popular AJAX frameworks such as Dojo, Bindows, and Prototype. (See Figure 5 and Figure 6 for samples of IDEA's Struts support.)
 Figure 5. IDEA Struts Web Application Setup |
 Figure 6. IDEA Struts Assistant |
JSF Development
Just like its Struts counterpart, the JSF project options are an exercise in flexibility: you can choose which JSF version (1.0, 1.1, or 1.2) and implementation (JSF RI or Apache MyFaces) you're going to use, and then IDEA can even download the required libraries for you (and it displays productivity hints while downloading the JARs—now that's attention to detail). NetBeans team take note: this is exactly the kind of broad support for all popular open-source frameworks or implementations (instead of just Sun-sponsored ones) that is missing in your IDE. Also, the JSF module provides out-of-the-box support for JBoss Seam, which by all accounts seems to be on the way to becoming the standard framework for JSF development (similar to the way Struts was for JSP). This is further proof that IntelliJ is well aware of cutting-edge development in the Java web world.
Refactoring seemed fully JSF-aware (e.g., moving a managed bean to a different package properly updated faces-config.xml). (See Figure 7 and Figure 8 for samples of IDEA JSF support.)
 Figure 7. IDEA JSF New Web Application Setup |
 Figure 8. IDEA JSF Configuration |
IDEA provides thorough support for the J2EE specifications. More importantly, it provides full-blown support for EJB 3.0 and JPA, although not quite as well as NetBeans yet (which automatically adds entries for the JPA provider in the persistence unit and generates code for named queries on all entity fields, something that I found missing in IDEA after getting used to it in NetBeans 5.5). IDEA does come with the option to view the ER Diagram for a JPA Persistence Unit, but unfortunately this seems available only in an EJB module. When using JPA in a regular web module, I was not able to invoke the ER Diagram option. Aside from this minor gripe, IDEA's overall J2EE/Java EE 5 support is top notch. It even offers an upgrade path from J2EE to the annotations-based approach of Java EE 5!
As far as application servers go, IDEA provides deployment plugins for all the major players, namely WebLogic, WebSphere, JBoss, Geronimo, and Glassfish.
For unit testing, it supports JUnit4 and provides an integrated tool for measuring code coverage as well.
Eclipse 3.2.2 "Callisto"/MyEclipse 5.1.0 GA
| Vendor: | Eclipse Foundation |
| Website: | www.eclipse.org |
| Price: | Free (base distribution)/Open-Source |
| Vendor: | Genuitec |
| Website: | www.myeclipseide.com |
| Distribution: | MyEclipse IDE |
| Price: | $49/year subscription |
Installation
On Windows and Linux the base Eclipse distribution is just a simple .zip or .tar.gz file that you extract in whatever directory you deem necessary. This provides you with a bare-bones IDE that is basically capable of creating a "Hello World" program, but not much else. In order to turn Eclipse into a workable environment, one has to download extra plugins from the Eclipse website (available directly from within Eclipse via Help -> Software Updates -> Find And Install). The ones I was most interested in were the Visual Editor (for SWING GUI building), the Web Tools Project (for JSP support), the JSF Tools, and Dali (for JPA support). The last two are officially declared as "preview" and not yet at version 1.0.
When it comes to installing new plugins, Windows was straightforward. Under Linux, it is possible to download Eclipse from a standard repository (most Debian-based or RPM-oriented distros feature Eclipse), which integrates perfectly with the way Linux applications are usually installed. However, this method installs Eclipse into a system directory (e.g., "/usr/lib/eclipse" under Ubuntu/Kubuntu), which can be updated only if running as root or with root privileges via 'sudo'. Unfortunately, Eclipse seems unaware of this and downloading the plugins ended in an error since Eclipse did not prompt me for the root password when attempting to install them under the restricted "/usr/lib/eclipse" folder. It would be great if Eclipse enhanced this little detail in a future release. As a simple solution, I just copied the entire local Eclipse installation to a folder in my home directory and was able to install all the additional plugins without any further issues (I guess I could have just logged into a session as "root," but I prefer to avoid doing that).
MyEclipse comes with a Java-based installer that under Windows integrates perfectly with the OS (including shortcuts) and does an acceptable job under Linux (although it does not create any desktop shortcuts).
General Features
When Eclipse appeared on the scene, its amazing, fast, and feature-rich Java editor was quickly recognized as its crown jewel. Among its attributes were:
- Fast performance
- Powerful refactoring
- Quick fixes for errors
- The ability to fix/organize imports
- Lots of polish seen in little details (e.g., attractive Javadoc pop-ups on code completion).
It indeed is a top-notch editor in every meaning of the term.
I was not as fond of Eclipse's windowing system, in particular its perspectives/views paradigm (I hated this same system back in NetBeans 4.0 as well, but they were wise enough to replace it). I very much prefer the simple approach of having all the relevant editors/palettes/panels configurable in a single window, without the confusion of perspectives. Admittedly, that is a matter of personal preference though.
I also found some aspects of the windowing system to be illogical. For example, minimizing the "Package Explorer/Hierarchy" view does not collapse it to the side (as I would expect from working with other IDEs, be it NetBeans or even Visual Studio.NET). Instead, Eclipse just folds it up and leaves a large portion of the screen unused—a very unusual design decision. (See Figure 9 for an example of this strange windowing behavior.) Besides that, the overall windowing system is quite capable, but I prefer NetBeans's system much more.
| Figure 9. One of Eclipse's Unusually Collapsed View |
Swing Development
The Visual Editor in Eclipse was by far—at least a mile—the weakest GUI builder of any of the major Java IDEs, mostly because the most advanced layout it supports is GridBagLayout. After working with NetBeans's Matisse, I could never imagine myself going back to that ancient and cumbersome method of creating Swing UIs. Fortunately, in what is a testament to the power of the community that has grown around Eclipse, MyEclipse delivers the Matisse GUI builder integrated directly into Eclipse! And it works very well, although obviously it will always be a few updates behind the cutting-edge enhancements that the NetBeans team is continuously adding to it (such as the bean binding feature that is supposed to be delivered as part of NetBeans 6.0). Nevertheless, the mere fact that Matisse is available on the Eclipse platform (even if it is part of a commercial solution) highlights why it is the 800lb. gorilla in the Java IDE space: none of its competitors have a similar community of plugin developers that are willing to complement (or sometimes replace entirely) Eclipse's base functionality.
JSP/Struts Development
The Web Tools Project (WTP) adds web-development features to Eclipse. It is quite capable for basic JSP development, offering a solid JSP editor. However, deploying your web application seems to be somewhat flaky. It often locked up with errors when I was deploying it to Tomcat. This was in direct contrast to the other IDEs, which did not exhibit any of these issues.
The WTP also lacks any built-in support for Struts development, which seems to be a major hole in its functionality (although a quick search at www.eclipseplugincentral.com revealed no less than 24(!) plugins for Struts support, both commercial and open-source). To no surprise, MyEclipse fills this hole quite thoroughly with full Struts support, including graphical editors for struts-config.xml, as well as wizards for creating new Actions and FormBeans (Figure 10 shows its Struts editor in action.).
| Figure 10. MyEclipse's struts-config.xml Editor |
Eclipse with MyEclipse added was also the only tool to provide a visual editor for creating JSP/Struts pages. (See Figure 11 for a sample of the capabilities MyEclipse can add to a web project.) Unfortunately, I was not able to test it thoroughly due to an Eclipse bug that disabled it under Linux.
| Figure 11. MyEclipse's Web Project Options |
JSF Development
The base Eclipse distribution provides a preview version of its upcoming support for JSF development. Despite its "preview" status, it is actually already quite usable and, dare I say, better than some of its competitors' supposedly more mature JSF functionality. This includes a visual editor for the faces-config.xml, code completion in JSP pages for managed beans' properties, new managed bean wizards, as well as visual editors to set up Converters, RenderKits, and Validators. I am excited to hear that the Eclipse team is planning to release a visual JSP/JSF editor as well. MyEclipse's JSF functionality is very similar in scope, but in my testing the base Eclipse JSF support was more than adequate.
Enterprise Development
Eclipse does not provide official support for JPA yet. It does have an incubation project called Dali that is geared to deliver this functionality, but it's still in the fairly early stages of development. Although I was able to generate a working set of entities from a database with it, however, even though the generated code wasn't quite at the level that NetBeans currently generates (e.g., it did not have any named queries created automatically). If your shop has not moved to JPA yet and is using straight Hibernate instead, then consider MyEclipse an option as it has quite a rich level of Hibernate support.
For J2EE development, Eclipse supports creating EJB and EAR modules, although in order to avoid J2EE's complexity it seems to be focused on generating EJBs via XDoclet, which admittedly was the best solution available before Java EE 5 and EJB 3.0 dramatically reduced enterprise application complexity. MyEclipse extends this functionality by providing additional wizards for session beans, message-driven beans, and container manager persistence beans, also driven by XDoclet.
Neither Eclipse nor MyEclipse currently seem to have Java EE 5 support, but considering it is still a fairly new specification I presume the Eclipse Foundation is busy adding this for a future release. (See Figure 12 to see MyEclipse's J2EE 1.4 EJB wizards.)
| Figure 12. MyEclipse's EJB Code Generation |
IDE Strengths by Development Area
I will be the first one to admit that no review is perfect. The respective team behind each IDE probably could make counterarguments to the many points in this article. It is simply impossible to evaluate all the possible development needs (and this review barely covered topics such as RCP, UML, JUnit, and reporting support), so obviously your choice of IDE should be based heavily on the particular Java technology with which you are most comfortable.
Each of the IDEs reviewed here can do an admirable job in pretty much every facet of Java development. However, some are better than others, depending on whether you are doing Swing, web, or enterprise development. So I organized the review summary into these subject areas.
Swing Development
If your shop specializes in Swing development, NetBeans is definitely the way to go. Matisse is simply way ahead of the competition. If for corporate reasons you have no choice but Eclipse, then I definitely suggest MyEclipse with its Matisse4Eclipse builder. After those two choices, I would rate IDEA (due to its support for JGoodies Forms) next and Eclipse's default Visual Editor dead last—way behind any competition. It should simply be avoided, period.
JSP/Struts Development
Things are a lot more heated here. I would give a clear advantage to IDEA, followed by MyEclipse, and then NetBeans. Due to lack of build-in Struts support, the base distribution of Eclipse isn't much of a contender.
JSF Development
The three are in quite a tight race in this category as well. Once again, I feel IDEA comes out on top here, followed closely by Eclipse/MyEclipse, and the basic support offered by NetBeans in last place. Admittedly, this ranking would look a lot different if you take the NetBeans Visual Web Pack into consideration (assuming its limitations are acceptable), which would move it into the front of the pack.
Enterprise Development
For JPA support, I would rank NetBeans first (simply due to the quality of its generated code and support for properly setting up the persistence units), followed by IDEA, and lastly the still limited functionality of Eclipse's Dali project. If you are willing to abandon the standard JPA approach and accept straight Hibernate as an alternative, then MyEclipse becomes a worthwhile contender as well.
For enterprise development, I'd say IDEA wins out with its rich support for both J2EE and Java EE 5, followed closely by NetBeans (which also does an impressive job here), and last is Eclipse/MyEclipse (mostly due to their current lack of support for Java EE 5).
Ignore .NET at Your Own Peril
If Eclipse is the 800lb. gorilla of Java IDEs, Microsoft is a menacing 10-ton King Kong somewhere in the background. As someone who has done a lot of work in C#/.NET in the past few years, I keep quite up to date on what Microsoft is doing in .NET 3.0 and its next version of Visual Studio (codenamed "Orcas"). I hope none of the Java IDE vendors are getting too comfortable and resting on their laurels, because Microsoft is putting a massive amount of R&D effort in both libraries and development tools. Thus, the Java ecosystem can remain healthy only if it can match that (or even better, exceed it as in my humble opinion it has done with Matisse, JPA, and EJB 3.0).
Companies and technologies that have ignored Microsoft's impact have usually ended up in the dustbin of IT history (and I write that as an ex-Sybase/PowerBuilder developer who has seen a once great tool mercilessly crushed under the weight of both its own mistakes and Microsoft's seemingly never-ending resources). I am very glad to see that the mistaken old Java mentality of "release the APIs first and then wait for the development tools of varying quality to appear much later" is being aggressively replaced with "release the APIs and world-class development tools for them as soon as possible", since that is exactly what Microsoft has been doing for years.