内容摘要 -
HotSwap：在Java中HotSwap技术给程序的调试带来非常大的方便，比如可以让程序一边调试一边修改代码，代码修改以后在程序中立即就可以看到修改后的效果，不用每次修改以后都要重新启动程序；在.Net中几乎不允许这样做，只有在非常苛刻的几个情况下才可以实现在调试状态下修改代码，而且一旦代码段被执行过了就肯定不允许再修改了，这就导致每次修改代码都要频繁启动程序，非常繁琐。
2、基于.Net的东西和Windows结合过于紧密，而且和Windows平台下一些旧有技术有太多千丝万缕的联系，导致用起来非常麻烦。比如每个对外部系统暴露的接口传来传去最后看到的类型是_ComObject，要想得知其真正的接口类型就必须通过COM技术来取得，非常麻烦；开发的很多组件都需要到注册表中注册，增加了部署的难度。
全文 -
配置是保存在Workspace中的.metedata目录下的，因此在开发插件的时候会把插件的配置信息自动写到Host起来的那个Eclipse的Workspace中，被调试模式启动的Eclipse所做的一些修改不会影响主Eclipse，而在Visual Studio中虽然可以使用Experimental Hive方式进行插件开发，但是由于这些配置是保存在注册表中的，所以被Host启动的Visual Studio实例会污染到主Visual Studio，每次重启IDE都需要运行“Reset the Microsoft Visual Studio 2008 Experimental hive”来进行环境的重置，且重置耗时非常长，浪费了大量时间；
（5）VS2008中，如果插件中抛出异常，而又没有捕获的话，轻则VS2008会显示一个错误消息框，重则VS2008会宕掉；而在Eclipse中会将插件中未捕获异常显示出来并且输出到日志文件中，方便插件开发者排查插件的Bug。
（6）Eclipse中工程相关的特性是以Nature的方式提供的，一个Nature通常可以挂接到几乎所有的工程类型中去，包括用户自定义类型；而在Visual Studio中工程相关的特性则是以SubProject的形式提供的，往往只能挂到Visual Studio内置的少数几个工程类型中去（比如CSharpProject、VBProject），这样可扩展性大大降低了。
（7）Eclipse中可以使用JET来开发非常复杂的代码生成器，而Visual Studio中的代码生成则只能用非常简单的代码模板机制，复杂的逻辑就必须通过字符串拼接来完成；
eclipse的体系设计很好，而vs2008几乎不可能转型成为eclipse那样完全基于OSGi的设计。
因为M$投入的人年太多了，很难想象推倒重来而且还要经受住工业化的测试。
而eclipse因为它免费，另一个是因为它在java ide里几乎没有遇到竞争对手，所以它可以从容的大修大改。
eclipse2.0的版本是不支持increment compile的，要编译就全体编译，-_-!
eclipse2.1后面的版本，几乎每个版本都有API改动。而且更新非常快，快到Milestone版本里API都不一样。这时候为eclipse写插件几乎没法维护，且不说换个版本就编译不过，而且某些个必须功能只存在于M版本里，而这些M版本几乎都有这样那样的bug。
3.0后eclipse又遵循OSGi重写底层代码，不过API稳定很多。当然3.0到3.3改动还是很大，不过大方向已经稳定了。
不过根据我对JDT的认识并不存在Eclipse Compiler，而是基于AST的词法分析。你能即时启动主要是因为你Ctrl-S的时候class已经编译好了，后面只是javaw的问题了。
而.net每次当你修改后代码启动的时候都重编译一次工程
|
