Eclipse 3.3 or NetBeans 6.0?

看到了一篇两者的比较，转帖过来：http://www.javaworld.com/javaworld/jw-03-2008/jw-03-java-ides0308.html?page=1

Eclipse 3.3 or NetBeans 6.0?

Finally, there's a decision to make!

By Andrew Binstock, JavaWorld.com, 03/18/08

Andrew Binstock compares popular favorite Eclipse 3.3 and recent Jolt award winner NetBeans 6. Find out how these free, open source development environments compare out of the box, feature-for-feature, and gain insight into the hidden quirks and bonuses that could make deciding between them easier.

There is perhaps no area of programming tools where competition is as intense as in the Java IDE market. Even though there are only four primary players -- Eclipse, NetBeans, IntelliJ IDEA, and Oracle JDeveloper (Rational and CodeGear JBuilder build on Eclipse) -- all vendors except Oracle watch their competitors intently and rush to add new differentiating features. (Oracle's product is primarily aimed at internal use and at buyers of the company's Fusion Middleware stack.) The competition is most intense between Eclipse, NetBeans, and IntelliJ IDEA, likely because those products have the most active communities of users and those users tend to be personally attached to their preferred environment. Of the three, only Eclipse and NetBeans are free and open source.

The timing of this review is driven in part by the release of NetBeans 6.0 in late 2007. This new version is probably the most important in the product's history -- a history that predates the other IDEs. NetBeans was first released by Sun in 1999, after it was acquired from a Czech firm; it was open-sourced a year later. During most of the intervening years, NetBeans has been an inferior product to Eclipse. No matter how much you might have disliked Eclipse, switching to NetBeans was not a wholly palatable choice. It had brilliant features, no doubt, but it lacked basic conveniences all the other IDEs offered. As a result, those who tried NetBeans often found it a frustrating product.

Sun finally got the message and during much of 2007 it completely revamped the IDE's editing functionality. In a fit of surprising candor, the project leads specifically announced that their goal was to provide an editing experience similar in quality to that of IntelliJ IDEA, a product distinguished by its friendly and intuitive interface. NetBeans 6.0 fulfills much of this mandate and has really elevated itself into the same tier as Eclipse. For the first time, serious Java developers have a true choice when it comes to free, open source IDEs.

This review looks at NetBeans 6.0 and Eclipse 3.3/Europa side by side, comparing them out of the box based on the principal factors that typically weigh in the choice of an IDE. The review concludes with a graded checklist, which is based on my weightings and priorities. You can use the checklist as a framework for evaluating which IDE best suits your needs and preferences.

The out of the box experience

Both IDEs are simple to download and install. For this review, I examined Eclipse v3.3.1.1 (Europa) and NetBeans v6.01. The download Websites for both products offer various configurations of features and plugins to match your project needs.

Eclipse installation consists of unzipping a download file. As long as you have Java 5 installed on your system, simply clicking on the Eclipse icon will get you started. Once you do, however, you are confronted with an annoyance particular to Eclipse -- workspaces. A dialog box appears and asks you to specify your workspace, which is defined in this dialog as the place where Eclipse will put your projects. Why do you need a workspace and what pieces of your projects go there? Does test data go there, do integration tests? You can't tell and -- here's the rub -- Eclipse won't tell you, because this dialog has no Help option.

If you later create a project and don't place it at the first-level subdirectory of your Eclipse workspace, you receive an error message. If you click on the Help button to find out more information, the help system takes you to a generic menu, from which you have to work your way back through the links to the dialog in question. Even then, the insistence on projects being in first-level directories is never explained or even mentioned. The help system in Eclipse is one of its most conspicuous weak points, and the need for workspaces as special project areas is one of its peculiarities.

Installing NetBeans is better but not without dips in the road. For example, if at the time of installation on Windows, the JDK is not specifically located in C:/Program Files/Java, the installation fails with a dialog stating that no instance of the JDK was found. NetBeans does not ask where the JDK is located: it simply doesn't run. It does give the option of re-running the installation from a command line and specifying the location using a command-line switch, but it provides no example.

NetBeans 6 assumes that you are familiar with the GNU conventions of command-line parameters used by the JVM. Because both Eclipse and NetBeans tout themselves as IDEs for multiple languages (more about that below), there is no reason to think that a developer using any language but Java would know or should care about what the JVM expects. If you've tried installing packages on an unfamiliar VM, you'll quickly appreciate the frustration caused by this carelessness.

Once installed, NetBeans is easier than Eclipse to load with an existing project. A wizard pops up asking for the directory tree for code and for tests and it intelligently loads both. You need only specify any needed libraries it doesn't know about. You can have projects anywhere on your disk. Like most Java IDEs, NetBeans has no equivalent of the Eclipse concept of a workspace and imposes no similar requirement on the location of your project files.

The editing experience

Eclipse has the more visually appealing interface of the two IDEs. The fonts on the Windows version are attractive and readable. (Less so on some versions of Linux, where fonts and line spacing are a long-standing issue.) It is pleasant without ever feeling excessive. Once you begin using features, however, you'll come across a unique and frustrating design issue: dialogs have a tendency to pop up spurious error messages. For example, Figure 1 shows a dialog box in which files are being imported into a project (click to enlarge).

Figure 1. A false Eclipse error message

At the top, an error message states that the move is illegal. As you can see toward the bottom of the dialog, the destination for these files has not yet been specified. And still, without knowing the destination, Eclipse balks that the files are being imported illegally. Most experienced Eclipse users have learned to see past Eclipse's false error messages and ignore them. Nonetheless, it is a singularly poor design that makes the product unfriendly to new users. To be fair, NetBeans also does this on occasion, but far less frequently and with better help support.

Eclipse uses other designs that are unique among Java IDEs: he principal one being the concept of perspectives. The idea is that you can click to a new perspective and all of your windows will change to a new context. So, you could go from a Java perspective to a debugging perspective and all (or many) of the windows in the IDE change from editing support to debugging tasks. NetBeans and other Java environments generally merge new windows into tabbed panes inside the currently open windows. Whether you like the wholesale changes of Eclipse perspectives or the more common incremental approach is a matter of individual taste. The benefit of perspectives is that if you load a plugin that uses many windows (for example, a screen design tool) it is easy to switch back and forth between that plugin and your current IDE setup.

As to the pure coding experience, both IDEs have many helpful features. It is not likely that you will need to do something in Java code that you cannot do comfortably in either IDE. This is one of the reasons that Java IDEs are envied by developers working in other programming languages, with the possible exception of C#. As outlined in Table 1, both products offer similar editing options, although not identical.

Table 1. Editing features

Feature	Eclipse 3.3	NetBeans 6.0
Code refactorings	22	17
Generates	Getters/Setters and similar, javadoc, unit tests, UML	Getters/Setters and similar, javadoc, unit tests, UML, BPEL
Spell checking comments and literals	Yes	No
Other Java-related editors	JSP, JSF, XML, HTML	JSP, JSF, XML, HTML

In addition to pure editing, both products do background syntax monitoring (Eclipse does background builds) and they quickly inform you of errors in your code that prevent successful compilation. Both provide intelligent auto-completion and generation of simple items, such as getters and setters. Eclipse and NetBeans also can generate unit tests for JUnit, but in both cases these tests are no more than stubs.

Language support

Eclipse and NetBeans have increasingly positioned themselves for use in a broader range of development domains by providing support for other programming language. For example, both IDEs provide good basic support for C and C++.

Eclipse officially supports C/C++, COBOL, PHP, and AspectJ. Its dynamic language toolkit project unofficially supports Ruby.

NetBeans supports C/C++ and two versions of Ruby: regular Ruby and JRuby, which runs on the JVM rather than the Ruby VM. The Ruby support is tip top. It has excellent editing features, plus debuggers for both Ruby variants as well as for Rails. In addition, Ruby Gems works right out of the box. These features make NetBeans the best IDE currently available for Ruby development.

Enterprise tools

Enterprise tools include functions normally used by larger businesses. These include modeling and reporting. The delivery mechanism for these tools highlights the difference in approach between the two IDEs. NetBeans tends to bundle, while Eclipse tends to make "platforms" available.

For example, when it comes to UML modeling, NetBeans has a built-in modeling tool that supports UML (including use case, class, collaboration, sequence, and activity diagrams). Code can be abstracted into a UML diagram, and UMLs converted to code. Eclipse, by comparison, offers the Enterprise Modeling Framework (EMF), which is a platform for building tools, and the graphical editor framework (GEF). If you install both of these packages, then configure them, you'll be ready to start modeling your enterprise architecture in UML. You'll have more features than you would in NetBeans, but you'll work harder to get them installed, configured, and running.

Profiling support is about the same. NetBeans has two profilers (timings and memory usage) built directly into NetBeans. At any point, you can click on the profilers and see how your program is doing. In Eclipse, you need to download the Test and Performance Tools Platform (TPTP), and from there, configure your tools and run. The end result gives you equivalent capabilities to what you would get out of the box using NetBeans.

The pattern described here carries throughout the IDE experience: NetBeans tends to bundle important plugins so that you can run them right away; while Eclipse makes platforms available, which then have to be downloaded, installed, and configured. In essence, NetBeans is the Mac to Eclipse's PC: that is, with NetBeans, everything just works out of the box, whereas with Eclipse you have to do more setting up and configuration. The trade-off is the greater range of options available in Eclipse.

Eclipse has no competition from NetBeans when it comes to reporting. Eclipse's Business Intelligence and Reporting Tools (BIRT) is an extensive system for formatting and generating reports and other documents that can be embedded in enterprise applications.

Plugins

Eclipse dominates in all aspects of plugins. This leadership position derives from two smart decisions its caretakers made several years ago: The first was to port the Eclipse underpinnings to the OSGi framework (formerly Open Services Gateway Initiative), which is designed to make writing new plugins particularly easy. Second was IBM's decision to spin off Eclipse, making it easier for the IDE to attract partners. Both moves succeeded brilliantly and Eclipse now enjoys a commanding lead in both open source and commercial plugins.

Nearly all new commercial plugins that ship for Java (such as recent Java products from Agitar and Enerjy) ship for Eclipse first. Actually, most of them ship for Eclipse only. A few are ported to NetBeans, but not many. So if you must have specific plugins, such as Mylyn (formerly Mylar), then Eclipse is your permanent home.

The profusion of Eclipse plugins is not a completely unalloyed benefit, however. Many plugins piggyback on other plugins and require specific releases of those subordinate components. This tree of dependencies can lead to a maddening process of loading, unloading, and configuration. For some users, it tends to make environmental updates a thing of dread. No less than Martin Fowler spent an entire day installing a single plugin due to this problem. 

Over time, some Eclipse users become less willing to update or add new plugins for fear the changes will cause other functionality to cease working correctly. A recent survey by BZ Research has shown that the number of installed plugins on average for an Eclipse instance shrank last year for the first time.

It is also worth noting that some very good plugins ship first on NetBeans -- notably the Ruby editor I previously mentioned and the Matisse GUI designer for Swing. Neither of those has a free counterpart for Eclipse, although Genuitec does offer a Matisse port for a fee. In addition, NetBeans offers one plugin that has no direct counterpart in the Eclipse ecosphere: top-of-the-line collaboration.

The enterprise collaboration plugin from Sun enables your team to communicate on its own IM network with special support for dragging and dropping files and code, as shown in Figure 2. To enjoy this collaboration, you can host it on your own messaging server (and point NetBeans at it) or you can use Sun's own servers on Java.net -- at no cost. Click to enlarge Figure 2.

Figure 2. The middle stack of panels from NetBeans 6.0 shows an IM session in progress and a previous file transfer -- all hosted on and routed through Sun's servers.

Because NetBeans is associated with Sun and does not use an OSGi-style architecture, its ecosystem of plugins will likely always be smaller than Eclipse's -- even if its market share improves substantially. So, identify the plugins you must have before choosing NetBeans and make sure they (or their equivalents) are available.

Rate 'em

Personal preference plays a uniquely important role in choosing the development environment you call home. Consequently, any head-to-head comparison that results in a rating will be useful to only the fraction of readers who weigh the given features the same way the reviewer does. To facilitate your ability to choose, I have listed the weightings for the features I think are important. You should change these weightings to reflect your preferences and then calculate your own final score. I use a four-point GPA-style scale, in which 2.0 is passing and 4.0 is the highest achievable grade.

Table 2. NetBeans 6.0 vs. Eclipse 3.3: Rated

Feature	Weighting	Eclipse 3.3	NetBeans 6.0
Ease of use/editing features	40%	2.8	3.6
Scripting/other languages	10%	3.0	3.6
Enterprise support	20%	3.2	3.0
Plugin ecosystem	30%	3.8	2.7
Total score		3.20	3.21

In conclusion

What is most striking about this review is that NetBeans and Eclipse are essentially tied. If nothing else, these numbers signify the arrival of NetBeans. For the last two years, I have performed comprehensive IDE reviews. During that time, Eclipse-based IDEs have regularly won top honors, while versions of NetBeans have lagged badly. This is the first review in which NetBeans truly stands on a par with Eclipse, and depending on your weightings could finish ahead. NetBeans has definitely arrived and is worthy of careful evaluation.

Author Bio

Andrew Binstock is the principal analyst at Pacific Data Works LLC. He is a columnist for SD Times and a senior contributing editor for InfoWorld where he reviews enterprise software and development tools. Find his blog at http://binstock.blogspot.com.