1、HotSwap:在 Java 中 HotSwap 技术给程序的调试带来非常大的方便,比如可以让程序一边调试 一边修改代码,代码修改以后在
程序中立即就可以看到修改后的效果,不用每次修改以后都要重新 启动程序;在.Net 中几乎不允许这样做,只有在非常苛刻的几个情况下才可以实现在调试状态下修 改代码,而且一旦代码段被执行过了就肯定不允许再修改了,这就导致每次修改代码都要频繁启动 程序,非常繁琐。 2、基于.Net 的东西和 Windows 结合过于紧密,而且和 Windows 平台下一些旧有技术有太多千丝万 缕的联系,导致用起来非常麻烦。比如每个对外部
系统暴露的接口传来传去最后看到的类型是 _ComObject,要想得知其真正的接口类型就必须通过 COM 技术来取得,非常麻烦;开发的很多组 件都需要到注册表中注册,增加了部署的难度。 3、Visual Studio 中代码的即时查错能力非常弱,很多的要到编译时才能知道代码是否有错;而在 Eclipse 中在编写代码的时候对于有错误的代码和有警告的代码(比如一些 Private 成员没有被引用) 可以立即清晰的提示出来,开发人员可以立即修改有错误的代码。 4、Java 中默认的方法都是可以 override 的除非标注为 final,而在 C#中必须是明确声明 virtual 的才 可以 override。在 Delphi 中也是类似的
问题,这应该是
Delphi 和 C#共同的老爹 Anders Hejlsberg 对 于 OO 的一种理念吧,也许人家大师的想法是正确的:一个方法是否是虚方法必须要明确指定。不 过对于习惯了
Java 中这种实现方式的人来说,C#的这种实现方式还是让人感觉一时难以适应的。 5、Visual Studio 的编译速度太慢,点击【调试】/【运行】按钮以后要编译好长一段时间才能启动(不 过和 Visual Studio6比起来现在的 Visual Studio 编译速度已经快多了了,已经接近于 Delphi 的编译速 度了) ;由于 Eclipse 使用的自己的高性能编译器 Eclipse Compiler,而且代码的编译是在编写代码的 时候即时进行的,所以在 Eclipse 中根本感觉不到编译的时间,点击【调试】/【运行】按钮以后程 序就运行起来的。 6、 .Net 类库中一些类
设计的不灵活, 比如 TreeView 的节点的显示的值是通过 Text 属性赋值上去的; 而在 Java 中的 Swing、SWT 等图形库中,可以在一个树节点中挂任何类型的值,然后通过为这个节 点定义个性化的 Render(渲染器)来决定这些树节点显示什么。 7、 Visual Studio 的插件体系过于死板, 开发起来不像开发 Eclipse 插件那样灵活简便, 这可能和 Visual Studio 插件体系的历史渊源有关系。举例如下: (1)比如要在代码编辑器上增加新特性,在 Eclipse 中可以通过代码编辑器中提供的大量扩展点来 实
现, 而在 Visual Studio 中的代码编辑器中则只提供了很可怜的几个可扩展性。 这一点是 Visual Studio 插件体系最大的硬伤,大大限制了基于 Visual Stuio 的插件的功能,相信随着 MS 对 Visual Studio 插 件体系的逐渐重视,这一点会慢慢跟上来的。 (2)Visual Studio 的插件体系和.Net 结合过于紧密,在 Eclipse 中可以为 Python、Ruby、C#、C、 ASM 等很多语言开发 IDE(提供代码编辑、代码辅助、调试、编译等功能) ,这些语言不必与 Java 有任何关系,而在 Visual Studio 中虽然也可以为一种语言编写 IDE,比如 IronPython、J#,但是这些 语言是和.Net 集合紧密的,比如要为这种语言提供调试功能,则必须将代码编译成 MSIL 代码,这 对于很多语言来讲是不可能的; (3)Eclipse 中的插件只要在自己的 plugin.
xml 文件中配置好就可以了,把那个插件的 jar 包放到 Eclipse 中就可以运行,而 Visual Studio 中的插件则必须首先
注册到注册表,调试和部署起来非常麻 烦; (4)Eclipse 运行时的配置是保存在 Workspace 中的.metedata 目录下的,因此在开发插件的时候会 把插件的配置信