在当下这个项目开始的时候，我们尝试使用NetBeans作为开发工具。也许是由于之前一直在用Eclipse，先入为主了，我总是发现NetBeans在一些地方似乎有先天的不足。于是在一周后，项目移到了Eclipse中进行开发，到现在依然在为没有太晚做这个决定而庆幸。

先从表面现象来比较。Eclipse的图形界面是SWT，而NetBeans作为Sun的产品，当然不好意思不用Swing了，于是给人第一印象就不好。某些系统上，dockable的窗口标题字体与标题栏高度明显不符，很不协调。输入中文时，候选窗也不能跟随光标移动——现在的Web开发一般都使用大屏幕显示器，你需要不时地看看屏幕的角落。别人可能会觉得奇怪——你有什么急事吧？要不然怎么不停地看时间呢？

在Eclipse中我习惯打开一个资源管理器窗口，从中复制一些文件，然后切换到Eclipse窗口直接粘贴到Package Explorer合适的目录。这一习惯在NetBeans里行不通，只能在IDE内部复制、粘贴。

然后透过现象看看本质。在NetBeans选中一个文件，按F2，你就发现，文件后缀是不能修改的！如果你想把一个.jspf改为.jsp，只能在资源管理器中做。看来NetBeans的理念就是傻瓜——比Windows还要傻瓜。

SVN集成。NetBeans默认集成了SVN，乍一听很让人兴奋。确实，当我看到单个文件中都有图形化的svn diff的时候，兴奋地跑到隔壁去找人倾诉。不过等到commit的时候我就开始沮丧了，完全没有subclipse方便、直观（subclipse 1.4不好，到现在我仍然在用1.2）。

最让人郁闷的是，J2EE项目中，在资源管理器里新加一个文件，在NetBeans刷新出来，部署时仍然会被忽略掉！仔细想想才明白，原来是要执行svn add才可以……合理乎？不合理乎？这svn集成，用一个词来形容就是“天衣无缝”。Web application部署都考虑到svn了，真是周到，佩服，佩服。

NetBeans的项目配置文件太过复杂，不适合作代码管理。nbproject下一堆文件，大部分是ant build file. 如果有library引用，肯定是绝对路径。在Eclipse里，即使有定制classpath，只要手动改成相对目录就一劳永逸了，svn co到任何地方都直接打开没有任何问题。NetBeans可不一般，改成相对目录可以，只要再新加入一个jar包，已改为相对目录的还会变成原来的绝对路径。

这不由得让人怀疑，NetBeans傻瓜吗？不，它很强大，很灵活，要不然配置文件怎么会一大坨。那这么复杂的配置文件，svn怎么管理啊？哦……svn集成很完美——web app部署都会考虑到代码管理。

x坐标一端是傻瓜，一端是灵活；y坐标一端是天衣无缝的svn集成，一端是复杂到天衣无缝的svn集成都无能为力的配置文件。天才的NetBeans在这个二维空间里找到了那个独一无二的完美的点，就像宇宙中只有一个地球一样。我错了，我是火星人。

Refactoring. Refactor – Encapsulate field，没有全选、取消全选的按钮。同时已有getter/setter的方法没有体现出来，但是你硬要选上的话，它又会抛出exception.

Refactor – Rename，没有同时重命名getter/setter的选项。

从某种程度上说，NetBeans很像MS的产品——大部分用户做傻瓜，小部分人是精英，为傻瓜们解决不应该是问题的问题。我做不了精英，却不想做傻瓜，于是还有一条路——我逃了。

嘿嘿，有许多人推崇NetBeans。确实，NetBeans某些方面比Eclipse做得好，比如上面提到的文件内svn diff，还有对于web开发很重要的——更好的JavaScript编辑器、HTML编辑器。还有其它的我还没来得及发现就放弃了。本文也就是发发牢骚，顺带给想比较这二者的同仁们抛砖引玉。