Might JavaOne have been NetBeans' last stand?

Might JavaOne have been NetBeans' last stand?

Summary: If you were a member of the press and a pre-registered attendee to JavaOne, you would have, in the weeks preceding the annual Java lovefest, had the dubious honor of a flood of e-mails from the public relations folks who represent the many members of the Java ecosystem.  This is not unusual in the weeks leading up to some big event.

SHARE:

If you were a member of the press and a pre-registered attendee to JavaOne, you would have, in the weeks preceding the annual Java lovefest, had the dubious honor of a flood of e-mails from the public relations folks who represent the many members of the Java ecosystem.  This is not unusual in the weeks leading up to some big event.  But as e-mail upon e-mail arrived from the ether, a pattern began to evolve that caught my eye given that this was JavaOne: repeated mention of the Eclipse integrated development environment (IDE) or the organization in charge of its oversight, the Eclipse Foundation vs. no mention of its competitor NetBeans.

Big deal you say. Bigger than you think. Ever since IBM bootstrapped the Eclipse Foundation with some funding and the open sourcing of a goodly chunk of the source code that was in its WebSphere Application Developer (WSAD) tools, the Java community which consists not just of developers, but also of third-party development tool makers, has been the rope in a power-play/tug-o-war between the IBM-emboldened Eclipse Foundation and the Sun-endorsed NetBeans.org

At issue? How the IDEs of each philosophically and technically treat the local resources on the systems that will run the Java applications they put out.  Fundamentally, the Eclipse Foundation believes that Java developers should be able to incorporate some awareness of the underlying operating system into their applications.  For example, the ability to make Java windows appear and behave more like Windows' windows or KDE's or even Mac's windows for that matter.  Or the ability to directly refer to local files using the local file-system's native access methods versus reliance on one of Java's slower but more portable application programing interfaces (eg: Java Service Request 51).  The key word in that last sentence, and to the Eclipse/NetBeans wedge, is portable.  The minute any Java application incorporates any operating system -specific awareness into its code -- something easily done when developers use the Eclipse IDE -- the final code will include operating system dependencies that violate Java's chief tenant of portability: software that's written once will run anywhere (on Windows, Linux, OS X, Unix, etc.) as long as a certifiably compliant implementation of the Java Runtime Environment is present on the machine. 

Sun, the inventor of Java, has long maintained that once you dispense with such portability, then you're not much better off with a Java application than you would be with any other non-portable application (one written for Windows for example).  As such, it should come as no surprise that the Sun-backed NetBeans makes no allowances for OS specific code the way Eclipse does, and therefore philosophically, it enforces the promise of portability that Sun wants Java to stand for.

Meanwhile, the Eclipse faithful argue that they're not forcing developers to build OS specific code any more than owners of passenger cars are forced to use hi-octane gas.  It's there and you can use it and just because it might give your car a little more pep or clean the carbon out of your engine's cylinders doesn't necessarily mean you do it.   Car owners are apparently mature enough to make their own decisions, and, it stands to reason that so too are Java developers.  Furthermore, some argue that the Java Community Process (JCP)  -- the organization responsible for creating the portable APIs that might obviate the need for natively applicable code -- moves too slow.  One case in point is the successor (JSR 203) to the JCP's current standard for file-system access (the aforementioned JSR 51).  As can be seen from JSR 203's home page, the anticipated schedule for delivery is currently TBD (to be determined), but is slated for delivery with the next version of J2SE -- version 6.0 codenamed Mustang.   However, there are reports on the Internet that, in addition to missing the release of J2SE 5.0 ("Tiger", the currently available version), JSR 203 will also miss Mustang.  Behind Mustang is J2SE 7.0, codenamed Dolphin.  

Whose right?  Whose wrong?  Honestly, I could vociferously debate both sides of the argument.  But at this point, such debates may not matter.  That's because, as in many tug-o-wars, someone is going to end up with mud in their face and despite Java inventor James Gosling saying at this year's JavaOne that "NetBeans is a long way from being dead," that someone, as of this JavaOne, is Sun and the members of the NetBeans camp. 

Though the organization still exists, and the IDE is getting lots of downloads (so says Sun, but let's be honest, download counts are a crock),  NetBeans is ready to be pronounced dead, and here's why.  Like operating systems, IDEs are the foundations of their own ecosystems.   The word "integrated" in "integrated development environment" is there because of how easy IDEs make it for developers to mix and match their favorite development tools.  Coding tools, modeling tools, workflow tools, mobile tools, etc.  There are hundreds of specialized tools out there that make it easier for developers to develop correspondingly specialized applications.  The beauty of the IDE is how all of these tools can be snapped together like a jigsaw puzzle and work together in one context.  So, in ecosystem terms, in the same way that computer buyers like to buy computers for which many applications exists (eg: Windows computers), developers will not only gravitate towards IDEs that they like, but the ones for which the most third party support and tools exist (known as IDE plug-ins). 

So, if you're looking for the IDE ecosystem for which 2005 has so far been a hands down banner year, that IDE is Eclipse.   Eclipse may have turned its biggest corner, when, during a 10 day stretch in January 2005, it signed Borland, BEA and Sybase, and then Computer Associates as strategic members.  Then, earlier this month, on June 6th, Macromedia came on board as well   saying it "plans to deliver a next-generation rich Internet application (RIA) development tool based on Eclipse."  Macromedia isn't alone.  Both BEA and Borland - major heavyweights in the Java development space -- have recognized the vibrancy of the Eclipse ecosystem and have decided that they're better off making sure that their own IDEs (WorkShop and JBuilder) are compatible with Eclipse's plug-ins rather than asking developer tool vendors to make separate plug-ins for their previously non-Eclipsesque architectures.  

In a press release from earlier this year, Borland said its customers will be able "to take advantage of the rapidly growing Eclipse ecosystem, plug-ins and advancements on the Eclipse open source projects." These victories weren't just a wins for the Eclipse Foundation.  They're also wins for developers because, finally, in the IDE world, developers have a situation where multiple IDE providers are complying with a specification (the Eclipse framework), and competing on implementation.  Ecosystems generally take off once a few heavyweights decide to compete in this fashion.  And taking off is exactly what Eclipse is doing.  While I normally hunt down executives for real quotes as opposed to excerpting press releases, today is an exception because there's no need to question the claims that the vendors are making.  The excerpts below, all of which came from the flood of releases that came out during JavaOne are tangible evidence of the enthusiasm for the Eclipse ecosystem -- enthusiasm that most ecosystem founders dream of.

  • JavaOne News: Catalyst Systems' Openmake 6.4 For Eclipse - Compatible with a variety of development language and tool environments including Eclipse-based solutions like IBM Rational Application Developer for WebSphere Software, Borland and Microsoft .Net. Openmake integrates fully with version control systems from Rational, Serena and more.
  • Sybase Announces Unified Eclipse-Based Application Development Environment - Using the Eclipse platform, a popular open source Java-based plug-in framework that makes it easier to create, integrate and utilize software tools, Sybase WorkSpace offers comprehensive development tooling that automates mundane tasks and reduces the overall complexity of application development.
  • BEA Systems Embraces Open Source Innovation - In addition to the support and leadership BEA has shown as a strategic member of the Eclipse Foundation, and as contributor to high-profile Apache and other open source projects, today’s news furthers the company’s position in open source and Java development. To bring all this to life, Carges demonstrated on stage during his JavaOne keynote the creation of a Java application in Eclipse leveraging both Apache Beehive and Spring with deployment to Apache Tomcat.
  • Compuware Extends Java Development Automation and Announces Eclipse Support With OptimalJ 4.0 - Compuware Corporation (NASDAQ: CPWR) today released Compuware OptimalJ 4.0, unveiling new process-modeling functionality and announcing support for the Eclipse open source development platform.
  • Oracle Strengthens Commitment to Java Developers with Free Development Tool and Open Source Projects - Oracle is proposing to spearhead a JavaServer Faces (JSF) tooling project within the Eclipse Foundation open-source community and will also join the Apache MyFaces project as a core contributor.
  • Borland to Ring In New Era of Java Innovation at JavaOne - We believe initiatives like Eclipse, distributed team collaboration, process optimization and model-driven development will take center stage in the next era of Java development. We’re excited to showcase to the Java community our ongoing innovations in these areas...At the conference itself, Borland will lead three sessions on topics ranging from how to leverage the Eclipse framework, to IDE extensibility, to recent innovations in JBuilder.
  • ILOG Delivers Enhanced Business Rule Management for Dual-Platform Applications - ILOG Business Rule Studio 2.1 also integrates in Eclipse 3, which is the most widely used Integrated Development Environment (IDE) for Java developers.
  • NEC is the 100th Organization to Join Eclipse - The Eclipse Foundation, an open source community committed to the implementation of a universal development platform, today announced that its membership has reached the milestone of 100 member organizations. NEC is the 100th organization to join the Eclipse Foundation and will join as an Add-in Provider member. NEC plans to introduce new Eclipse-based tools and plug-ins for their C++ and Java development environments.
  • OC Systems Announces Hitchhiker for Eclipse - "As Eclipse has grown beyond being a Java IDE, it has become increasingly important that testing, profiling, memory analysis, and coverage tools be available for native code. Our Aprobe instrumentation technology allowed us to quickly integrate these capabilities with Eclipse," said Oliver Cole, president of OC Systems. "Hitchhiker is our first foray into the C/C++ space within the Eclipse ecosystem. We look forward to receiving feedback and developing future Eclipse-based products, particularly for C/C++."
  • NDS Announces New OCAP Software Tool for Eclipse Development Environment - NDS Group plc, the leading provider of technology solutions for digital pay-TV, today announced the immediate availability of a new plug-in for its OpenCable Applications Platform (OCAP) version of its widely popular MediaHighway Development Kit (MHDK) Advanced..... The new plug-in speeds open standards-based set-top box application development and offers superior debugging features. It is compliant with the latest version of Eclipse, the most popular open source development platform today.
  • Open Source Leader Exadel Extends Eclipse IDE with New Visual Editing Tools - Exadel, Inc., a leading provider of software, services, and support that enables companies to create mission-critical business applications based on open source and Java technologies, today announced the availability of Exadel Studio Pro 3.0, an advanced enterprise-class Web application development suite designed to work with Eclipse 3.1, the widely used Integrated Development Environment (IDE) platform.

To be fair, I dug around to see NetBeans had any sort of similar buzz. 

To keep the measurement down to third party interest, I excluded anything from Sun or IBM.  For example, that Sun's director of NetBeans in the Java and Developer Tools Group Timothy Cramer said that Sun "is fully committed to the NetBeans platform for tools" doesn't count.  Nor did I count Sun's contribution of more code to NetBeans (eg: the 135,000 lines of collaboration and infrastructure source code it took from its Java Instant Messaging and Java Studio Enterprise products).   Also, I'm throwing out the standing room-only turnout at NetBeans Day 2005 where James Gosling and Jonathan Schwartz were the headline acts.  Think about it.  You're a JavaOne attendee.  You already have a proclivity to soak up what Schwartz and Gosling might have to say.   They could have called it "Mad Cow Disease Day" and you would have attended.

So, with the playing field leveled, NetBeans scored a zero on the buzz meter.  But it gets worse.  I actually took the bait when a couple of vendors -- BEA and Sybase -- offered me an opportunity for a JavaOne briefing with their executives.   These are two very big companies that play in the Java ecosystem.  BEA also claims to have the largest number of J2EE application servers in production.  So when BEA's CTO Mark Carges explained why the company with the largest number of Java application servers in production is banking on Eclipse, you can't help but listen.  Here's what he said in an interview that you can download:

 

I spent the last two and half years out with customers when we launched our WebLogic 8.1 and was out there meeting with them on how they’re going to build portals with it and business processes and so on and so forth and pretty much the feedback I got universally was we love the WorkShop environment and the experience you get when you develop with it.  But especially about a year ago when [Eclipse] really started to turn up, we really heard loud in clear, "But you know developers are using Eclipse based plug-ins and IDEs. It  be great would be if we could take advantage of that."  Not one of the companies I met said the same for NetBeans.  So it was a very very simple choice.  We looked at it and said at this point in time, the Eclipse organization has the right kind of open source model, it has the right meritocracy as far as how you can contribute and how code could be developed.   IBM did a very nice job of separating themselves from that.  Eclipse did a very nice job running themselves as an open source organization where anyone could participate. We felt very comfortable joining that organization and leveraging that for one, and two, it was what customers were asking for.  It was a no brainer.

"No brainer" kinda sticks out in my mind. OK. So does the part where Carges said no one (no one from the supposedly largest base of production J2EE servers) asked for NetBeans support. Sybase is apparently equally nonplussed when it comes to NetBeans. Sybase VP of marketing Kathleen Schaub  is quoted as saying "The IDE market is converging. .NET and Eclipse are becoming the standard. That's a big change." Echoing her sentiment was Sybase's director of application  development technologies Karen Frederiksen who told me (you can download the audio): 

We didn't really have a debate internally about Eclipse vs. NetBeans. When we first started doing development on Eclipse with our Unwired Orchestrator product was in late 2002 and at that time Eclipse was a little farther along and so when we got towards developing with workspace and really started planning for that product, our developers and our engineering team just had more familiarity with Eclipse and it was working for them and we decided to move forward with Eclipse....[In 2002, Eclipse] was better suited to our needs at that time... We haven't had much call for [supporting NetBeans] but of course, you can never tell what's going to happen in development environments and if NetBeans gets some good momentum and we have demand for that from our customers... I don't like to ever say never...Those sorts of controversial questions are what keeps my job interesting.... [The controversy] doesn't really concern us that much.  We're committed at this point to Eclipse and we just try to stay out of the fray as much as we can. 

"Committed." 

Not surprisingly, this is the exact same language Sun uses to describe how it's in it for the long haul with NetBeans.  Earlier today, in a telephone interview, Sun's group manager for developer tools marketing Dan Roberts told me "We're completely committed to open communities and open standards and Netbeans as the base of our tools strategy."  But, in the same breath, saying "Eclipse has the largest market share," Roberts admitted that NetBeans is the underdog -- but one that he believes is fully capable of a "reinvigoration." 

In fact, Robert's believes that such reinvigoration is already underway.  Confirming that a count of first time downloads of the NetBeans (or any other software) is not the best way to measure the growth or size of the NetBeans community, Roberts says that Sun has been counting the number of unique developers that reconnect with the NetBeans.org Web site at least twice per month to get software updates and that the number has jumped from 45,000 to 138,000 in the last nine months.  Meanwhile, at this year's JavaOne, Sun is claiming that there are now over 4.5 million Java developers worldwide (the math works out to 3 percent).   Roberts also made the "competition is good" pitch, saying that it's the fact that Eclipse has had so much success that it has motivated the NetBeans' faithful to a new wave of innovations.   Roberts goes on to cite those innovations -- ones like the GUI builder Matisse that has striking similarities to Microsoft's Visual Studio (see the flash demo) --  as the sort of advancements that will captivate the interest of Java developers.

Indeed, the fact that NetBeans is on the cutting edge with GUI builders like Matisse or that it's often first out with support for the latest Java technologies (Sun has a nice inside track on Java that allows it to keep its tools and implementations about as current as current can be) is one of NetBean's strengths.  And competition is good for the Java IDE ecosystem.  Wrote Redmonk's Stephen O'Grady in his summary of the feud (more like a lamenting), "I believe that Eclipse is better because of NetBeans, and NetBeans is better because of Eclipse." 

So, technology counts for something.  Not only that, there's no reason Sun can't build innovations like Matisse for Eclipse.  But if you ask me, when it comes to ecosystems, third party support -- especially from the heavyweights -- counts for more.  Developers will have to consider the way the rest of the Java market is rallying around Eclipse before committing themselves to NetBeans as much as Sun has.  Finally, judging by the way that Sun appears to have thrown in the towel on its Linux-based Java Desktop System (JDS), Sun does have its breaking points.  I believe that that point is near for NetBeans.  Very very near.

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

17 comments
Log in or register to join the discussion
  • Oh my God, it's a really long post!

    David, very interesting post, but too long!
    Where do you find time to write so much?
    JoseCtesArg
    • Lesser the stuff, more the fluff

      David Berlind, you do not have a clue about Java. Please stop writing about Java.
      Van Der
    • Storage is free

      Thanks for the comment Jose. Glad you find the post to be interesting. Although I didn't stick perfectly to the inverted pyramid style of writing, you could have disengaged well before reaching the end and walked away with the main point. Since storage is virtually free, the constraint, as you imply is one of my time. While I took the time to provide all the backup, I'm not forcing you to take the time to read the entire thing. So, I'm not sure what your complaint is. Would you like access to my calendar so you can review how my time is budgeted and then let me know if you approve?

      David
      dberlind
      • A little snide?

        I think the complaint is easy to understand - we (me and the other poster) thought your post was too long and would have been better if it was shorter.

        You know, the whole hyper-text thingey, where you can target your main text to a reasonable length, and include links for the background information? If you need further clarification on why that makes more readable text, I'm sure I can find a remediary English class to pencil into your calendar for you.
        jcg_z
        • Healthy number of hyperlinks

          There are already a healthy number of hyperlinks in the story (it's not as though I'm unaware of hyperlinking). Again, I appreciate the feedback, and you're free to accuse me of publishing too much information. There was a day when I would break this up into smaller chunks. But that was also a day where I could turn copy over to an editor and let him/her worry about how to break it up, how to maintain flow, transitions, etc, and then hand that off to a web producer who would then worry about all the linkage and tying the package together. If we had to waited for me to do all that, then the story wouldn't have come out until next week. And some other stories as well as my ability to be responding here in the comments area would fall by the wayside.

          db
          dberlind
      • Don't defend yourself, I'm not attacking you

        I found your sentence somewhat rude: "Would you like access to my calendar so you can review how my time is budgeted and then let me know if you approve". Calm down David!

        Actually, there is no complaint. I'm not saying you force us to read the whole thing.
        Also I'm not criticizing you. Simply I want to know how do you get time to write so much, because I'm the kind of guy who is troubled managing his time. And you seem in the opposite side (i.e., you seem succesful in this). I just want to know how others do.

        BTW, I didn' read the entire post! :)

        Regards,
        Jose
        JoseCtesArg
  • Berlind and Java

    The only thing David Berlind can be indicted on is that he tends to confuse ignorant, arrogant snot-nosed punks with his professionaly thorough presentations accompanied by corroborating facts. Such a professionalism tends to mess with the minds of nit-wits.
    donald17
  • What I don't understand

    I tend to agree with the Netbeans side of the arguement. If you are going to put platform-specific code in Java, then why not use .NET? Write-once, run anywhere is the Java mantra - and losing that would kill it.

    This kind of "forking" ALWAYS happens. If you "force" people to do something a particular way - they will squirm until they get what they want. Even if they have to write it themselves. IBM loves this kind of action - they are ALL FOR PROPRIETARY solutions - but how to convince OSS programmers to do it? AH, give them a FRAMEWORK! Hey that critical Eclipse app ONLY works with P-series, and we'll be GLAD to sell you one (plus support)!

    Here's what I don't understand. People complain that Java is slow - obviously adding a layer in between the application and the OS slows you down. But you SHOULD be able to take advantage of the platform-specific abilities when you build the JVM. If disk-access is slow, then you tune it for maximum effect - inside the JVM, and the source-code for a Solaris JVM and an AIX JVM could be COMPLETELY DIFFERENT! But in the end you get faster Java execution. SO where is the emphasis - (JVM) source code compatability between platforms, or custom-written code for faster platform execution? Unless you put a platform-specific in the JVM, people will put in their own apps . . .
    Roger Ramjet
    • Roger, you answer your own questions

      Sun suffers from the same malady as you do. Rabid anti-MS bias.

      Riddle me this - fundementally what is the difference between with IBM pulled off with Eclipse and what MS did with their version of Java from waaaay back when? MS was evil because they broke Java - and put in API's that were specific to Windows. Shock, oh how horrible. But IBM does the same thing (oh, okay, so they include hooks for Linux so I guess that's okay) and Eclipse is the darling.

      Anyway - Sun backed themselves into a mental corner with all the fighting with MS regards Java. My guess is thought to include OS specific hooks into the JVM was probably viewed as burn at the stake heresy. My hunch is based on the inadvertant release a couple of years back on the internal memo from Sun Solaris engineers - how they would absolutely refuse to have anything to do with Java as it was not reliable enough for their purposes. The wagons had circled on the Java side of the house, and you were gonna get write once run everywhere and that was it.
      quietLee
      • It's not all rabid anti-MS bias

        In response to this thread and a conversation that I had yesterday, I've posted some details on one legitimate slippery slope that Sun is desperately trying to manage.

        See http://blogs.zdnet.com/BTL/?p=1571

        db
        dberlind
      • Eclipse User Here

        Well, no, Microsoft was changing the java.* classes, whereas
        Eclipse provides separate classes to glue the platform-specific
        swt windowing to the applications. Embrace, Extend and
        Extinguish, my friend, Sun had to fight it.

        For what it's worth (small-time semi-pro developer) I use Eclipse
        because, on a Mac, not having to remember it's not the Cmd key
        is very useful. I keep up with Netbeans and I use it whenever I'm
        required to build gui clients, because platform independence is
        important to my deployments. That having been said, I use
        tomcat/jsp and browsers for most of my gui work these days
        and so I'm in eclipse.
        DannyO_0x98
    • Eclipse is portable...

      "I tend to agree with the Netbeans side of the arguement. If you are going to put platform-specific code in Java, then why not use .NET? Write-once, run anywhere is the Java mantra - and losing that would kill it."

      Eclipse doesn't put platform specific code into Java. They mearly allow native widgets to be pushed by Java. And they allow this ability on Windows, Linux, Solaris, AIX, MacOS X, QNX, WinCE, and other platforms. That sounds pretty portable to me. Granted that if you used Swing instead of Eclipse's SWT you'd be able to run on PalmOS, Simbian, and a few other platforms that SWT does not yet suppport, but basically Eclipse/SWT runs on every relevant desktop platform. Eclipse/SWT + Java is still VERY portable and is not the lock-in technology like .NET GUI development is.

      Further, Eclipse is not controlled by IBM. Many organizations other than IBM are benefiting from Eclipse.

      So what's there to complain about? Java has two great GUI technologies: SWT and Swing. Both are mature, elegant, and have unique advantages. I write both SWT and Swing applications and I enjoy using both technologies.

      "This kind of "forking" ALWAYS happens. If you "force" people to do something a particular way - they will squirm until they get what they want. Even if they have to write it themselves."

      It's called choice and it's a bennefit.

      "Hey that critical Eclipse app ONLY works with P-series, and we'll be GLAD to sell you one (plus support)!"

      Eclipse apps work with all of the platform's described above, there is no "critical Eclipse app" that runs on a pSeries that wouldn't run on a Windows or Solaris box just as easily.

      "Here's what I don't understand. People complain that Java is slow - obviously adding a layer in between the application and the OS slows you down."

      No one complains that Java is slow anymore. Java is fast -- nearly as fast as C++. Faster than .NET even when running on Windows (where MS should have the advantage). Java is significantly faster than Python or Perl. Swing used to be pokey, but Sun has really kicked it into high gear and Swing is pretty dang fast in Java 5. So the whole "Java is slow" myth is a thing of the past.

      I could go on, but blahhh...
      Java is cool. Eclipse is cool. Netbeans is cool.

      -Bryan
      prime21
      • ...except it's not

        Would not run on either Solaris 10 AMD64 or Fedora Core 3 AMD64. So, I'll stick with IntelliJ IDEA and Netbeans that do work.

        IBM is blessed that the arena of OSes is less crowded these days. They'd be porting SWT day and night...
        denka@...
        • Check again...

          Goto http://download.eclipse.org/eclipse/downloads/drops/R-3.1-200506271435/index.php

          Notice the download for Linux x86_64 (as well as Linux PPC, and Linux ia64).

          Indeed there is not a download for Solaris x86 (32 or 64 bit), however, Solaris has a stable API. SWT is open-source. Download the Solaris SWT code onto your Solaris x86_64 box and type "make"... Or just wait. I'm sure eclipse.org will have Solaris x86 downloads soon.

          I'm not saying that Eclipse/SWT is the end all be all. Nor am I saying the Swing isn't a great technology. I am however saying that Eclipse/SWT is very portable (though not as portable as Swing).

          -Bryan
          prime21
  • Nobody is talking about features

    While Eclipse has wonderful plug-in support and a great architecture, I am sure I am not the only one who is tired of trying "Mix up" a fully functional J2EE environment in Eclipse. Netbeans, OOTB, supports, html, jsp, xml, xst and a host of other things that I have yet to find in a convenient or complete package for eclipse. Eclipse is fine for most things but I really like not having to find plug-ins to support common, standard functionality. I think Java IDEs should support java standards, including J2EE.
    My 1.865434 cents
    sher1
    • Eclipse and Netbeans J2EE features...

      Netbeans does indeed rule at J2EE/Java Web development. However, Eclipse does have a standard plugin for J2EE/web development and supports all of the things you've mentioned above. You have to install the J2EE (actually it's called the Web Tools Platform --- aka WTP) plugin after you've installed Eclipse.

      Find out more here:
      http://www.eclipse.org/webtools/

      -Bryan
      prime21
  • Recently won over to Eclipse...

    but I admit I haven't used Netbeans in a long time (years). Back then it was a slow, feature-bloated, memory hog.
    debuggist