我所理解的JAVA和 DotNet

Java

　　从实用性来讲，Java 可以说是第一种“网页”语言。尽管像 Perl 等语言会突然发现它们处理字符串的能力在恢复价值和发送 HTML 到网页浏览器上是天生的，但是 Java 是最早发现自己是根植于浏览器中，最初是在一个有趣但却非常古怪的 HotJava 浏览器（基于 Java 本身进行编写），而之后又以现有浏览器的扩展形式呈现出来。

　　尽管从表面上看其结构与C和 C++ 类似，但是 Java 的后端表现却与这两种语言不同。比起编译 Java 源代码到原生及其代码中，Java 编译器将编译由 Virtual Machine 或 VM 所运行的“字节码”。Java 字节码是一种汇编语言，但却不是与特定处理器有关系的汇编语言。Java VM 是字节码的运行时解释器，将为你的机器目标处理器解释字节码。这一方法的优点在于，如果目标及其拥有可兼容的 Java VM 或 Java 所承诺的“编写一次就能够在任何地方运行”，你便可以在不同机器间移动 Java 字节码，并且可以无需做出任何改变而运行。这一方法的缺点在于 Java 字节码并不是原生机器代码，尽管像“及时”编译器能够完善 VM 性能，但实际上你是在运行时间做一些解释，这将引起较小但却可衡量的性能打击。

　　还有其它缺点便是，Java 的现实性并不符合语言的早期承诺。尽管在网页中执行游戏的理念几乎能够马上让所有人动心，但现实是 Java VM 并不能与所有内容兼容，使用特定 VM 而编写的 Java 应用或支程序可能不能运行于带有其它 VM 版本的机器上。“编写一次就能够在任何地方运行”被改为“编写一次便能够移植到任何地方”，也就是说一旦你完成你的 Java 代码的编写，它便能够有效地运行于一个平台上，然后你所面临的重要任务便是确保你的应用能够有效运行于所有系统上。

　　Java 的第三个缺点便是源自其 GUI。尽管首次“传递”促使 Java GUI 使用原生的 OS 控制（按键，滚动条等等），较小且较快，但却没有深度。下一次传递 Swing 虽然看起来好多了，但是表现仍然很早，并且完全不同于最初的控制。最糟糕的是 Sun（Java 之父），太慢了，难以添加现有的 OS 功能，就像关于 ClearType 字体渲染的支持。因此，Java 应用总是着眼于一些与现代化不着边的版本。

　　但是在服务器编程方面，Java 便扬眉吐气了。VM 的一大优势便是，它并非真正的处理器，只是一个模拟，所以销毁 VM 并不是多大的问题。如果你对于 Java VM 感到困惑，这并不会真正影响基本的操作系统，你大可以选择关闭并重新开始，并且不需要重启整个机器。再加上 Java 的内存管理模式是源自 C++ 和C语言，所以像分配内存（无需将其带回之前的系统）这样的问题便不再是多大的问题了。像这样的系统非常适合服务器环境。服务器可以突然出现并在必要的时 候消灭 VM 且不会对潜在 OS 造成任何影响。同样地，GUI 问题也并不适用，如果你的服务器软件看起来并不壮观，它便一点都不重要，除非你想要给服务器管理员留下深刻印象。今天你将会发现许多商业大型多人游戏在服 务器端使用了 Java。Three Rings 的多人游戏便是个很好的例子，他们不仅在客户端，同时也在服务器端使用了 Java 语言。

　　Java 发挥重要作用的另一个领域便是手机市场。J2ME（Java 2，Micro Edition）是带有删节类程序库（游戏包注：专门为在手机和其它较小的设备上运行而设计的）的 Java VM 的微小版本。实际上，如果你包含了手机目标群体，Java 可以说是现在最受欢迎的平台之一。

　　优点：Java 的 Virtual Machine 加上其内存管理和不再需要的内存的自动收集让你能够创造非常诱惑力且足以避免被摧毁的软件。它同样也带有强大的扩展文件传统。

　　缺点：Java 的“编写一次便能够在任何地方运行”的承诺未能兑现。Java 类程序库已经经过多次重新编写且未删除早前的调用，所以即使程序库与早前的代码是反向兼容，似乎还有三种方法能够做到一切，除了因为“过时”而被拒绝。

　　可移植性：非常不错，但却不像想象中那么棒。基于 Java 创造一款可移植且能够使用潜在的 OS 最新功能的应用与在 C++ 上这么做一样困难。

　　是否适合新手：非常适合。尽管在不遭遇弃用对象的前提识别执行某项任务的“正确”方式对于那些还在摸索语言的新手来说有点困难，但是语言本身的核心是很容易理解的。同样地，Java 也是许多大学课程的标准语言。

　　

　　.NET Languages（特别是 C# 何 Visual Basic）

　　.NET 是微软对于 Java VM 的基本答案。实际上，.NET 是以整体技术命名的。真正的 VM 名字是 CLR（公共语言运行时），之前所谈论的关于 Java VM 的一切内容都适用于 CLR，但也有一个例外：CLR 从一开始便不是用来“匹配”单一语言，就是 Java 那样。因为这样，有许多语言使用了 CLR 去执行后端处理。不管是像 COBOL 和 FORTRAN 这样的早前语言还是像 Python 这样的现代语言都能够瞄准 CLR。需要提醒你们的是，有些 CLR 项目是小型的单人项目，所以如果你在 CLR 版本中找到你最喜欢的语言也不要太过兴奋，因为在这里有些编译器还不够成熟。

　　微软所开发的 C# 和 Visual Basic 都是最受欢迎的 CLR 语言。C#是源自 Java 的语言，它带有 90% 的 Java 语法，尽管从表面看它更像是源自C或C++。C#拥有一些很棒的语言扩展，即基于 Java 慢慢添加的内容，并重新编写了类程序库。

　　简称 VB.NET 的 Visual Basic 是 CLR 执行以及对于微软已建立且受欢迎的 Visual Basic 环境的替换。尽管它仍被称为“Basic”，但却不再是全部大写，它与早前的 BASIC 解释器（贯穿于 20 世纪 80 年代所出售的所有计算机的 ROM 中）只带有少量的相似处。现在，它的语法与本列表中的其它语言非常相似，尽管它仍然未使用括号去整合某些内容。它同样也使用了更具对象导向型“点记法”去 调用功能而不受语言的前 CLR 版本的更大的功能程序库。

　　优点：尽管 Java 并未投入太多努力面向 Java VM 编译语言，但是 CLR 从一开始便是为了支持这一点。因此存在许多基于 CLR 的语言，并且它们很容易进行互通。

　　.NET 技术获得微软的 Visual Studio 环境的大力支持，而这也是一个非常成熟且具有丰富的功能的开发环境。

　　C#对于微软的 XNA 技术来说应该算是首要的编程语言，这是创造在 Windows 和 XBox 360 游戏主机间可移植游戏的一种方法。

　　缺点：与 Java 不同的是，CLR 应用不能像网页中小程序那样运行。尽管“Silverlight”技术允许这点，但是对于游戏来说这却太迟了，并且不能像 Java 和 Flash 那样根植于浏览器中。

　　基于 CLR 的应用比想象中更难移植。

　　可移植性：尽管存在第三方将 CLR 移植到到除 Windows 外的其它操作系统，但是基于这一方向的努力却远小于面向 Windows 的努力。所以尽管你可能面向 Windows 创造一个非常有活力的 .NET 应用，但是你在 Mac 和 Linux 上的执行却不会多么顺畅。

　　是否适合新手：都适合。这两种语言都是很直接且容易理解的。此外，它们与 Visual Studio 环境的紧密关系也让设置变得更加简单。