NetBeans 4.1 can't import Eclipse 3.1 projects and I go on a rant about both

Just a short note to the NetBeans' folks. NetBeans has a module that allows you to import Eclipse projects into NetBeans. It appears that it only works for Eclipse 3.0.x projects. I've since moved on to Eclipse 3.1. Well, when I read how one developer felt that Eclipse failed to meet his enterprise java development needs, I got all fired up (again) to give NetBeans 4.1 (not 4.2) another chance as my primary IDE. To start with I tried to import a project I was currently working on from Eclipse to Netbeans.

So I went to the NetBeans website import pages and attempted to follow the simple and clear directions. The problem I found is that the NetBeans import plugin only works for Eclipse 3, not Eclipse 3.1. When I attempted to import a project out of an Eclipse 3.1 workspace, NetBeans 4.1 failed. It did not recognize the workspace and would not allow me to pick the project to import.



And as you can see below, the workspace directory structure does exist and it works quite well for Eclipse.



The Truth About Eclise and NetBeans (at least in my eyes)

First, let's get one thing straight. I think both IDEs suck, they just suck in different ways. Let me count the ways.

1. Editors. I have spent years moving back and forth between emacs (and emacs-like editors) and vi (especially vim) and putting up with the holy wars between the two camps. When I attempt to use another tools editor, it usually offers an emacs emulation mode (hell, even Visual Studio offers it). Eclipse does make an attempt to provide emacs key-bindings. NetBeans does not. In Eclipse 3.1 the common editor preferences are now in one spot (number of spaces/tab, substitution of spaces for tabs, line numbering, etc). With NetBeans you have to touch each and every editor for every file type. If you have more than one type of file to edit (Java, JSP, XML for example) then you get lots of practice setting editor preferences in NetBeans.
2. Core Java Editing. Eclipse has the best core Java editing environment. When I'm in the Java perspective (and yes, I do like the idea of perspectives) I can look at three panes to quickly find my warnings and errors. On the left is the Package Explorer where I can see the error and warning icons on each package and file. At the bottom is my Problems pane that keeps track of everything and allows me to find every individual problem in my source files. And of course there is the source editor which shows each line where there is a problem. Those features have helped me more times than I can remember when developing Java applications. Gerard Fernandes is correct that those panes can get out of sync on occassion. I've had that problem, which is corrected only by a rebuild of the project. Depending on how big the project is and powerful the machine you're own, it can go from very quick to excruciatingly slow. NetBeans will tell you if you have errors in your source code, but only in your source code editor pane. Warnings are non-existent. Errors that occur during a build will appear in the Output pane, and you can click on errors to open the offending source file at the line where the error occurs. But if you close the IDE you loose that information. Eclipse's built-in incremental compiler helps maintain warnings and errors in the Problems pane. As each problem is corrected that problem is automatically removed.
3. Simple Database Support. NetBeans out of the box exceeds Eclipse when it comes to working with databases. Why? Because Eclipse provides absolutely nothing. There are plugins you can google down that provide the same equivalent functionality for free (SQLExplorer) that are unfortunately non-intuitive in their use, or you can purchase more powerful database editing and management capability plugins for Eclipse for lots of money. I'm a cheap bastard. So I'll take basic free capability any time, especially if I don't need fancy ERD/OR diagramming. My only complaint about the NetBeans database support is you have to know the name of the database before you can use it. It would be nice to have an automatic listing of all the databases (MySQL's show databases, for example).
4. J2EE Support. This is where NetBeans is headed and this is where NetBeans is strongest. NetBeans has a Runtime pane (a very nice feature) that allows me to support multiple J2EE servers. I added my local Tomcat 5.0 server and immediately picked up the ability to develop with all the web applications on that running instance. I also have the ability to work with JBoss 4. I have installed version 0.7 of J2EE Standard Tools/Web Standard Tools on Eclipse, but I have not yet attempted to use them. I will say that having to download an 89MB Eclipse IDE and then a 138MB JST/WST extension is a bit much when you can just get NetBeans at a more "modest" 46MB.
5. Plugin Hell. I have begun to feel the initial pains of Eclipse plugin version collision. Every plugin has its own unique version, and they vary within the overall Eclipse version release.Right now I can't use the Laszlo IDE because it's not yet been released for Eclipse 3.1. IBM has gotten into the bad habit of releasing, to much fanfare, new tools for Eclipse that will not run on the latest version of Eclipse, or that will not use the latest version of installed plugins. And that's getting to be really annoying. And that leads to:
6. Plugin Management Hell. You can get to the Eclipse plugin manager under Help | Software Updates | Manage Configuration. You can get to the NetBeans plugin manager under Tools | Setup Wizard | Step 2 - Module Installation. I would have not thought to look under Help for Eclipse, and certainly not Tools | Setup Wizard for NetBeans. The bigger issue is removing plugins. In versions before Eclipse 3.1 you could remove plugins. Not anymore. The only plugin management actions you can perform on an installed plugin with either IDE is either update or disable a plugin. If you want to remove a plugin you uninstall the IDE and then, after installing the bare-bones IDE, you make sure not to install the plugin you wanted to remove in the first place. That's a bit extreme. And that leads to...
7. Plugin Development Hell. NetBeans support for formal plugin development is non-existent. Eclipse's plugin development is obtuse. Both suck. Big time.
8. Plugin Updates. NetBeans plugin update service is the bee's knees. Eclipse plugin update sucks dead bears out loud.
   
9. Toolkit Selection.I don't care what the Eclipse camp says, SWT is not Swing. There's a lot I'd like to do with Swing that I can't with SWT. And mixing Swing with the SWT_AWT bridge is a big hack. And I don't care what the NetBeans camp says, Swing is not native and is slow and is still a lot of the awful things that Eclipse has said about Swing in the past. Although it has gotten better with Java 5. And I do like the look-and-feel of NetBeans 4. And I do like what they're doing with SwingX.
   
10. We Will Sell No Matisse Before Its Time. I'm old enough to remember Orson Wells shilling for Paul Masson wines. No matter what, drunk or sober, using Matisse for anything other than carefully crafted demoware or trivial mp3 players is a royal pain in the ass. I don't know if it's Sun trying to push on the NetBeans crew, or if the NetBeans crew were just honestly enthusiastic, but one thing should be absolutely clear: don't shill a new feature until it's reasonably solid to turn loose to people like me. My view of NetBeans has been tarnished by this particular episode, and I now look with considerably more skepticism on NetBeans that I did in the past, as well as announcements from its more vocal supporters.

So which one do I use? I use both depending on the task at hand and I have actually set projects up on my notebook that I share between both (OpenMap is the biggest so far). As far as I can tell it will stay that way for the foreseeable future.