Java 最吸引人之处，在于跨平台。而.NET 可以看作 Java 的改良版，囊括 Java 大部分的优点，所以当
然也具有跨平台的潜力。但是认真追究起来，Java 和.NET 的程序其实也不算真正跨平台，因为 Java 
VM（虚拟机器）和.NET VM 本身就是一个平台，而 Java 程序只能在 Java VM 上执行，.NET 程序只
能在.NET VM 上执行，至于 VM

 

的底下是什么操作系统，则无关紧要。

        更清楚的说，Java 和.NET

“

”

的跨平台，指的是跨 操作系统 平台。所以，Java VM 和.NET VM 能

移植到什么 OS 平台，Java 程序和.NET 程序就能跨到什么平台。从 1.0 版至今，Java 历经了近多年的
发展，Java 已经无所不在了。除了在服务器上已经取得压倒性的胜利之外，在桌面系统的安装比例也
已经超过 90%（2002 年的数据），且随着最近 Dell 等大厂和 Sun 签约在 PC 上预先安装 Java VM，此

 

数据未来会更高。

        但事实上，Java

“

”

跨平台的开放程度并不若我们所想象的美好，主要的原因在于 四不一没有 ：

        版本不一致：许多操作系统上虽然已经具备 Java VM，但是版本并未和最新版的 Java VM 同步，
甚至不同版本差距颇大者。举例来说，早期 Mac OS 在追随 Java 的脚步上，步伐很慢，往往差了一个
版本，例如在 Java 1.3 推出一、二年后，Mac OS 仍只有 1.2 版的 Java VM 可用（但是现在 Mac OSX 已
经追上 Java 的版本推进）。另外，Java VM 安装比例固然已经超过 90%，但是其中应该有许多仍是使
用 IE 浏览器内建的 Microsoft VM（只支持到 Java 1.1.4 API），不能执行 1.2 以后的 Java 2 程序。所幸

 

的是，版本落差这个问题近来已经有显著的改善。
   
        特殊动态链接库不存在：对于那些非 J2SE 标准的动态链接库（例如 Java 3D），往往只局限在
Window、Solaris、Linux

 

三个操作系统。关于这一点，我不认为未来几年内会有所改善。

   
        标准不够开放：Sun 曾经把 Java 提交给 ISO 来制订开放的标准，但后来又因为舍不得而撤回，
改成立 JCP 委员会为 Java 的标准制订单位。这也使得 Java 在开放程度上并未如宣传上所说的那么好。
（这一方面，.NET 还比 Java 好一些，至少核心部分已经是 ECMA

 

的标准）。

   
        厂商不服气：这可能会造成标准的分裂。早期微软在 Visual J++产品中就有一些可能造成 Java
分裂的举动出现。近年来关于 IBM 和 JBoss 等公司，在 J2EE 的产品上，和 Sun 也是屡次发生冲突。甚
至之前传出某公司有利用市场的力量，另立标准的可能。例如 Eclipse 的 SWT 就是一个和 Java 的
AWT/Swing 互相竞争的 API

 

。

   
        技术人员没有跟上新技术：过去这八年，Java 修修补补，废弃了一些旧的 API 和程序设计思维，
增加了许多新东西。如果开发人员未能随时补充新知识，仍用旧的方法开发系统，就会横生困扰。这
其实是很严重的问题。.NET

 

在跨平台问题也不少： .NET 某些 API 在设计时，并没有考虑到跨平台的

需求，例如 Windows Forms 就是如此。这会使得移植.NET VM 到不同操作系统时，难度会比较高 。
Mono（Linux 上的.NET VM）曾想移植 Windows Forms 到 Linux 上，但是后来放弃了，改成在 Wine
上面执行 Windows Forms（当然效率会因此变差了）。[但是再后来由于 System.Drawing 实现的比较好，
因而又基于 System.Drawing 来实现底层的 SWF，Mono 1.2 的发布就是等着 SWF1.0 的发布。当然效率
肯定比不上 Windows 下的 SWF。不过 Mono 是推举使用 GTK#的]    只有核心部分是 ECMA 的标准，
重要的 API 例如 ASP.NET，和 ADO.NET 都不是标准，而是微软私有的财产，可能涉及法律问题 。
Mono 另外推出 Gtk#这套 GUI 的 API（将 Gtk+

 

包装起来）。

   
        技术人员没有跟上新技术： .NET 经过了 5 年的发展，最新到来的 2.0 版本和 1.x 版本相比较，