语言跨平台特性

原文 

C为何不能跨平台

 

若是你们能对个人文章推荐一下，关注一下本人博客，那就更开心了，我从此也会更多的写一些计算机系统/原理类的文章，以飨各位读者。再次谢谢。前段时间看了 周志明的那本 《深刻理解java虚拟机》。对于平台无关性问题，有了一些新的认识。因此特写一篇博客来进行总结。

这是个人第一篇不针对具体技术，而只针对计算机系统和原理的博客文章，而这种话题，老是比较宽泛，而我本人的水平有限，因此我也只能泛泛的写写，思考的不对的地方，还望读者不吝批评。

C为何不能跨平台

我们先来讨论一下，C语言的执行过程，从而搞清楚为何C语言不能跨平台。

//@author www.yaoxiaowen.com 转载文章请注明出处。 // 本文地址：http://www.cnblogs.com/yaoxiaowen/p/7470460.html #include <stdio.h> int main() { printf("Hello, World!"); return 0; }

以上就是广大人民群众 都知道的hello world程序。最终执行的结果 就是在console上输出一行字符串， hello world!。

大学时，谭浩强的C语言教材，main方法的返回值是void，但这是错误的。实质上应该返回int来告诉操做系统执行结果。（固然，后来学习的深刻了，才知道谭的教材有很多错误的地方，可是我对这本教材依旧印象很好，由于那是我编程的启蒙教材）。

咱们知道，计算机只认识0和1(就是二进制)，换句话说，无论咱们在计算机上干了什么事情，运行了多么复杂的程序，从ps绘图，到qq聊天，再到听音乐，最终到了CPU的执行层面，其实就是 一串串的0和1组成的指令罢了。 固然，到了硬件层面，那就是与或非门的领域了。可是，上面的那个 hello world程序是怎么转换为0和1的呢。
通常状况下，对于咱们使用的是 IDE，好比 Visual Studio， CodeBlocks之类的，就是点击个运行按钮那么简单，或者你就是使用了gcc命令行来进行编译，也能够一行命令 gcc -o hello hello.c,就 输出了最后的编译结果。可是实际上，hello world的编译过程是这样的:

咱们分阶段来讨论:

• 预处理阶段。预处理器(cpp)来把 代码中#开头的行进行展开， 好比头文件，宏等内容，修改最初的C文件。
• 编译阶段。编译器(ccl)将修改后的C文件，翻译成了 另外一文本文件，hello.s，这就是咱们所说的汇编程序了。 打开这个文本文件内容 相似下面的格式：

//@author www.yaoxiaowen.com 转载文章请注明出处。 // 本文地址：http://www.cnblogs.com/yaoxiaowen/p/7470460.html section .data msg db 'Hello, world!',0xA len equ $-msg section .text global _start _start: mov edx,len mov ecx,msg mov ebx,1 mov eax,4 int 0x80 mov ebx,0 mov eax,1 int 0x80

固然，不一样CPU和平台环境，编译输出的汇编代码也不一样，咱们这里仅做为示例。

• 汇编阶段。汇编器(as)将hello.s翻译成机器语言指令。 把这些命令打包成一种叫作可重定位目标程序(relocatable object program)的格式，此时的输出格式就是hello.o了。这其实就是二进制文件了。
• 连接阶段。编译过程最后还有一个连接阶段(程序调用了 printf函数)，最后的输出结果仍是和上一步相似，都是直接二进制文件。

了解了 hello world程序的编译过程，咱们就来讨论一下，什么是汇编程序。咱们先来看一下维基百科上的定义。(那个维基百科的连接，没fan墙的同窗应该是打不开的)。

汇编语言（英语：assembly language）是一种用于电子计算机、微处理器、微控制器，或其余可编程器件的低级语言。在不一样的设备中，汇编语言对应着不一样的机器语言指令集。一种汇编语言专用于某种计算机系统结构，而不像许多高级语言，能够在不一样系统平台之间移植。

什么是汇编，相关专业的同窗应该都明白，由于计算机只认识0和1(就是二进制)，因此在计算机刚开始发明时，那些科学家们就是直接 向计算机输入0和1，来运行计算任务的。(固然，他们是经过穿孔纸带的方式来向计算机输入, 好比有孔表明1，没孔表明0)。经过这样的方式，计算机终于能运行了，可是这样的效率实在太慢了。

而在他们输入的0和1中，有些表明的是指令，这些是有固定含义和编码的。也是芯片能识别的。而另外一些是数据。这些不一样的程序的数据天然是不一样的。咱们前面就说，无论多么复杂的计算机操做，到了cpu级别都是0和1，数据虽然多变，可是 指令的数量是有限的。由于 指令是要被芯片固定识别的。芯片中要用 晶体管(最初是电子管)组成的与或非门组合来识别这些指令和数据。由于直接输入0和1,实在太繁琐了，因此他们就发明了汇编语言。来简化 程序的编写。

好比 计算 1+1，两个 数据1都 使用 0x0001 来表示，而 加操做，放在cpu中，能够是 0xa90df(这个是胡乱写的),这个二进制表明的加操做能被计算机识别。而由于这个加操做对于cpu来讲，编码的0xa90df格式是固定的。因此能够直接一个助记符add来表示，这样科学家们写程序就方便多了，而这就是汇编程序的由来。由于汇编程序完成以后，能够再有一个专门的程序（就是要上文中所说的汇编器）来把编写的汇编程序编译成0和1.这样计算机也能够识别了，而汇编语言自己也方便了程序的编写和阅读。

编写汇编比直接编写二进制方便高效了太多。可是 随着计算任务的复杂，程序的规模愈来愈庞大，使用汇编程序也很累啊，那么是否有更简单的方式呢？因此科学家们发明了高级语言(好比 C,lisp等)，在编写程序的时候，使用C语言等编写，而后再使用 编译器将C语言程序翻译成汇编程序，汇编程序再使用汇编器编译成0和1，这样，cpu能识别的东西没有变化，可是对于编写程序的人，确实方便了不少。

经过以上的描述，咱们就知道了高级语言的大概由来。也明白了咱们所编写的各类高级语言，到了最后，其实都是转化为二进制执行。

而直接二进制格式的程序，咱们称之为本地机器码(native code)。而相似那些 add之类的 助记符，以及汇编的编写格式或标准，咱们称之为 指令集。

可是问题的关键来了。不一样公司所生产的 cpu芯片。他们所使用的指令集不一样啊, 这种芯片设计的事情，又不像TCP/IP协议那样，有国际统一的标准，甚至像intel所表明的复杂指令集，和arm为表明的精简指令集，它们指令集的设计思路就是不同的。

因此 咱们C语言最后编译出来的的二进制文件，假设是这段93034030930900090222ab2d11cd22dfad(随便写的)，不一样的cpu上识别的意义是不一样的。

因此为何说C语言不能实现跨平台运行，就是由于它编译出来的 输出文件的格式，只适用于某种cpu，其余cpu不认识啊。

• 咱们所说的跨平台运行，并非指hell.c这个文本文件的运行。由于文本文件自己也没办法运行。运行的只是它的编译结果hello，而这个由0和1组成的编译结果，不一样的cpu和平台，他们的格式不一样。因此C语言编译出来的结果，没办法跨平台运行。

• 甚至在不一样的平台下，hello.c最后所编译出来的文件的格式都不一样。好比linux下编译出的hello,window下编译结果是hello.exe,而mac下编译结果是hello.out,(至于单片机上编译结果的后缀是啥子，这个忘记了)。

• 也有些人会讲，为了让linux下编写的一段hello程序运行在window上，我不拿最后的编译结果hello来直接运行，我在window环境下从新用IDE创建项目，一样的源代码在window下从新运行一遍，输出hello.exe，再在window上运行，行不行啊？这个答案是No。由于不一样环境下，c语言的标准有差异。例如 int类型，在有的平台上 可能16位表示，而有的平台上则是32位表示。因此不一样环境下的同一个程序，会存在数据溢出之类的错误。

• 其实还有一点，你们平时写个程序，IDE上点击个run/build之类的，稍等一会就输出结果了，可是实际上，不少大型程序的编译过程是比较长的，好比我第一家公司作手机系统的，编译一个Android5.0的系统rom，在i7 cpu，16G内存的电脑上，须要编译运行一个多小时，才能编译成功输出最后的结果。

知道了 C语言不能跨平台运行，那有没有一种办法，可以 让高级语言实现跨平台的运行呢?

思考实际编程中的一个场景，咱们前端须要处理的某个数据是A格式，可是后台只能提供B格式的数据，那咱们怎么办?很简单啊。写个接口，把B格式转化为A格式不就好了嘛。这就是设计模式当中的适配器设计模式。

关于跨平台也是同样的道理。cpu的指令集不一样， 不一样平台编译出来的结果格式都不一样，那么咱们能够在各个平台上运行虚拟机，而后咱们制定某种编译结果的输出格式，咱们的输出了某种格式的结果，直接在虚拟机上运行。这样不就ok了嘛。。

这其实就是 java采起的方式。

Class文件格式，虚拟机以及 ByteCode

这是java版本的helloJava;

//@author www.yaoxiaowen.com 转载文章请注明出处。 // 本文地址：http://www.cnblogs.com/yaoxiaowen/p/7470460.html public static void main(String[] args) { System.out.println("helloJava"); }

这段java程序编译出来的结果是 helloJava.class,换句话说，它输出的结果是Class文件格式(也叫字节码存储格式)。
class文件的内容大概就像下面那样：

是否是看不懂?看不懂就对了。这其实就是java虚拟机定义的二进制格式，这种咱们称之为 字节码(ByteCode),是java虚拟机所能运行的格式。相似本地机器码能够反编译成汇编，这种二进制也能够反编译成更容易阅读的格式。

相似下面这样。

而各个平台的java虚拟机 是不一样的。可是咱们编写的java程序 统一编译成特定格式的 Class文件格式，而后Class文件能够在各个不一样平台的java虚拟机上运行,固然运行结果确定也是一致的，至于各个不一样平台之间的差别，这是那些编写java虚拟机的人去考虑的事情，咱们这些作java的程序员，不用去关心这个问题。

经过这种方式，咱们的java程序就实现了跨平台。

因此java也被称为 中间件技术语言。意思就是 中间加一层过分。很好理解。（固然，维基百科上对中间件技术的解释，基本把我看晕了,也和java不要紧，不过你们理解这个意思就好）。

平台无关性

而经过java虚拟机和Class文件格式，咱们就实现了平台无关性,换句话说，这些适应各个不一样平台和cpu的工做的仍是要有人干的。那就是设计java虚拟机的人去作这些工做，可是他们的辛苦换来了咱们上层程序员的轻松。咱们就彻底不关心各个平台和cpu的差别了。

代码编译的结果，从本地机器码（NativeCode）向字节码(ByteCode)的转变，是存储格式的一小步，倒是编程语言发展的一大步

虽说名字是 ByteCode,可是我觉的，其实和 NaticeCode 都差很少，反正都是定义了一套指令集，只是前者能被虚拟机执行引擎去执行，而 后者能被物理机的CPU去执行罢了。

知道了大概的原理，咱们就思考另外一个问题，java虚拟机去执行Class文件，那和java的源文件 有什么关系呢。答案是 不要紧。换句话说，java的源文件编译的输出结果为Class文件，而Class文件能被java虚拟机认识，并执行，这是两个独立的过程，中间也没啥关系和必然性。

那么进而引伸出另外一个问题，某一种其余编程语言，若是我设计出了一种对应的编译器，将其编译输出结果为Class文件，那这样该语言岂不是也实现了跨平台了?

想到这一点，那么恭喜你，你发现了 java虚拟机的另外一种 重要特性。语言无关性

语言无关性

java虚拟机在执行Class文件时，不知道也彻底不关心这个Class文件是咋来的。(这个Class文件能够是任何一种语言的源文件编译而来，固然，就像直接编写汇编同样，你直接编写 ByteCode也行,只要格式正确)。
其实CPU在执行二进制的指令时，它不知道也彻底不关心这些指令流是咋来的。这都是同一个道理。

不少程序员都还认为Java虚拟机执行Java程序是一件理所固然和天经地义的事情。这是错误的。

下面某些内容 援引 周志明的 《深刻理解java虚拟机》：

Sun的开发设计团队在最初设计的时候就把Java的规范拆分红了Java语言规范《The Java Language Specification》及Java虚拟机规范《The Java Virtual Machine Specification》。

而且在1997年发布的初版Java虚拟机规范中就曾经承诺过：“In the future,we will consider bounded extensions to the Java virtual machine to provide better support for other languages”（在将来，咱们会对Java虚拟机进行适当的扩展，以便更好地支持其余语言运行于JVM之上）。

实现语言无关性的基础仍然是虚拟机和字节码存储格式。Java虚拟机不和包括Java在内的任何语言绑定，它只与“Class文件”这种特定的二进制文件格式所关联，Class文件中包含了Java虚拟机指令集和符号表以及若干其余辅助信息。基于安全方面的考虑，Java虚拟机规范要求在Class文件中使用许多强制性的语法和结构化约束，但任何一门功能性语言均可以表示为一个能被Java虚拟机所接受的有效的Class文件。做为一个通用、机器无关的执行平台，任何其余语言的实现者均可以将Java虚拟机做为语言的产品交付媒介。

换句话说，java虚拟机这个名字其实只是一个误导，java虚拟机和java没啥关系，其实更应该叫作 Class文件虚拟机。

由于其余语言， 只要有对应的编译器，输出结果就能够运行在java虚拟机上，因此时至今日,涌现Clojure、Groovy、JRuby、Jython、Scala一批运行在java虚拟机上的语言。

目前下图中的语言都已经能够运行在java虚拟机上。

因此广义上的java技术体系，也包括Clojure、JRuby、Groovy,Scale等运行于Java虚拟机上的语言及其相关的程序。

Java,Scale等各类语言中的各类变量、关键字和运算符号的语义最终都是由多条字节码命令组合而成的，所以字节码命令所能提供的语义描述能力确定会比单一语言自己更增强大。

固然，在java最初刚出现的时候，Write Once，Run Anywhere, 这种 平台无关性被吹嘘的比较厉害，可是如今 这种虚拟机的思想，被不少其余语言也学会了，好比python和pvm。go语言，.NET等都是一样的思想。

为何C/C++没有被替代。

关于java虚拟机和Class文件格式， 貌似很厉害的样子，什么 我的一小步，人类一大步都扯上了，那确定有人疑问，为何 c/c++这些不能跨平台的语言，还如今还被不少人使用，还没被java取代呢。

固然，这个缘由有不少，好比java的gc过程所没法避免的stop the world过程，这在 某些实时性要求比较高的 系统中，好比 股票交易系统，军事系统，是不可接受的。(关于垃圾回收这是另外一个话题，不在本文范围内，将来有时间能够花时间另写博客讨论这个问题)。

不过有句话说的很好
java和c++之间有一堵由动态内存分配和垃圾收集技术所围成的'高墙'，墙外的人想进去，墙内的人想出来

另外，对于直接与硬件交互的事情，也只能靠C语言了。毕竟上层再怎么发展，硬件与系统之间永远要存在一个驱动层啊。

可是除了以上这些，还有一个缘由。给你们讲讲软件历史上的一个重大教训，你们也许就明白了。

当年为了对抗sun的java平台，微软2002年推出了相似中间件思想的.NET平台(C#)。当时window xp一统江湖，让微软如日中天，不可一世，微软在下一代操做系统(就是window visa)的开发中，决定使用 C#， 虽然微软牛逼哄哄，拥有最牛逼的程序员，最顶尖的科学家，可是开发到最后他们发现，使用C#这种运行在虚拟机上的中间件语言，不管如何也达不到 C/C++语言的速度。因此最后悲剧的 window visa，所有推倒重来，从新开发。当时李开复在微软，他的一本书中对此有详细介绍。

固然，当年window visa项目的失败，还有其余一些缘由，好比 使用数据库系统代替文件系统，驱动不兼容等， 可是 使用.NET来进行开发，起码也是失败的主要缘由之一。

因此如今你们明白了，ByteCode运行在虚拟机上，相比于直接编译成 NativeCode 运行在物理机上，速度较慢。

如今随着虚拟机运行时优化技术的发展，以及硬件的速度愈来愈快，因此它们速度之间的差别，也没以前差距那么大了。

实质上，Class文件在虚拟机上运行的时候，还会有不少的优化措施。

在部分的商用虚拟机中，Java程序最初是经过解释器（Interpreter）进行解释执行的，当虚拟机发现某个方法或代码块的运行特别频繁时，就会把这些代码认定为“热点代码”（Hot Spot Code）。为了提升热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各类层次的优化，完成这个任务的编译器称为即时编译器（Just In Time Compiler，简称JIT编译器）。

许多主流的商用虚拟机都同时包含解释器与编译器。解释器与编译器二者各有优点：当程序须要迅速启动和执行的时候，解释器能够首先发挥做用，省去编译的时间，当即执行。在程序运行后，随着时间的推移，编译器逐渐发挥做用，把愈来愈多的代码编译成本地代码以后，能够获取更高的执行效率。当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可使用解释执行节约内存，反之可使用编译执行来提高效率。

可是实际上，编译器能够把java源文件的输出结果编译成Class格式(也就是 ByteCode)，那天然也能够有其余类型的编译器 能够直接将java源文件编译为NativeCode啊。因此对于编程语言来讲，咱们能够有各类方式来编译它，Java语言的“编译期”实际上是一段“不肯定”的操做过程。由于咱们可使用不一样类型的编译器编译出不一样的输出结果。

java常见的编译器有如下类型。

• 前端编译器：把.java文件转变成.class文件。好比Sun的Javac、Eclipse JDT中的增量式编译器（ECJ）。
• JIT编译器：字节码(ByteCode)转变成机器码(NaticeCode)。好比HotSpot VM的C一、C2编译器。
• AOT编译器：直接把*.java文件编译成本地机器代码。 好比GNU Compiler for the Java（GCJ）、Excelsior JET。

结束

因此讨论到最后，你们就已经明白，因此平台无关性，与 编译器与编译输出结果格式 的关系。花了一天时间写了这么多内容，也但愿给你们带来一些启发。

在本篇博客当中，不少内容也并非精确的分析，好比某些概念，都说的比较模糊，由于咱们这片博客只是讨论思想。不少概念和过程也都没有去深究, 若有错误不许确的地方，欢迎指正。

---

补充内容（20170905）

很是感谢你们对这篇文章的支持，可以对其余人有所帮助，得到你们的承认。更加提高了我坚持写博客的动力。

针对评论中的问题，也进行一些解答。

一

如文章末尾所说，我原本就是写大概思想，因此不少细节没有深刻去追究，其实好比像汇编的格式，指令集的执行等，其实这些讨论起来真心复杂，牵扯到cpu的结构设计等。从此也计划写文章和你们讨论这些问题。

评论中倒没有人指出这方面的问题，不过我大学时原本就是作C语言和单片机的，明白这方面介绍的依旧不够准确和详细。（固然，不少细节我也忘记了）

二

评论当中有人提到.NET的虚拟机的问题，首先由于我自己是Android程序员，大学时期也作过C语言，单片机等，因此对java，C等算是了解一些，可是对.NET的确不了解。对.NET有限的知识，也来源于和作.NET的朋友的讨论交流。所以关于.NET思想的评价可能不够准确。

评论中有人提出了如下问题：

wdwwtzy 评论： 那我想问问，.net 也是 java 同样的虚拟机技术，为何早期.net 没法跨平台？
隆德尔评论：楼主，据我所知，java与.net，此虚拟机非彼虚拟机。并且这个问题一直被不少javaer所混淆。
wdwwtzy评论：啥意思，看文章的意思，java 一出生不就是真正的跨平台了吗？

有些同窗直接评论作了相关解答，对此深表感谢。写博客原本就是一个相互讨论相互促进的过程，因此感谢各位的解答。

WindyAmy评论：.net CLR/.net framework 和window系统结合的太紧密致使。如今微软重写了部分framework库（.net core），已经能够实现夸平台了。
Blackheart评论：由于没有人在其余平台实现.net 的clr啊，后来有了mono，能够跨平台了。没有真正意义上的跨平台，对于开发者而已，可能你不须要关心操做系统是windows仍是linux了，你感受是跨平台了。可是底层总有这么一帮人在帮你搭建支撑“跨平台”的基础设施的，对于他们来讲，一个个的平台都须要单独去实现的。**

几位解答的同窗说的都已经很是好了，本人结合评论，也google了一些相关知识。再对.NET的相关问题写出个人理解。以期抛砖引玉。

• 能够肯定是，.NET和java虚拟机也是同样的思想，都是引入中间层/虚拟机的思想。作java的同窗说java虚拟机（JVM），而微软的.NET的虚拟机的名称叫作通用语言运行平台（Common Language Runtime，简称CLR）。虽然有些同窗可能认为CLR不叫虚拟机，可是归根到底，它仍是广义的虚拟机的概念和思想。

• Clojure、Groovy、JRuby、Jython、Scala等不少语言均可以运行在JVM上。而 CLR也是同样的，C#、F#、VB.NET、C++、Python等几十种语言也能够运行在CLR上。

• java，Scala等编译结果为ByteCode(字节码),被称之为Class文件格式运行在jvm上，而jvm在运行Class格式文件时，能够解释运行，也能够经过JIT编译器编译成NativeCode加快运行。而C#，C++等编译成 通用中间语言（Common Intermediate Language，简称CIL）,而后再汇编成字节码，（固然这个字节码确定不会是Class文件格式，可是概念相同），而在运行时，也是翻译成本地机器码运行（可是CLR貌似没有解释运行，这点求相关同窗解答，我估计应该也有相似javascript的解释运行方式，不过没查到相关资料）。

以上是技术层面，下面咱们再来讨论 一些非技术层面。

你们知道，咱们要想在某个平台上运行java开发的项目，必需要安装jdk，这个过程仍是很麻烦的，要设置环境变量之类的。这对于普通用户来说是不可能完成的操做。而.NET其实也是须要安装环境的（叫作 .NET framework），可是window就是微软自家的，因此window系统内置了.NET framewok。(win7自带.net3.5版本,win10自带4.0版本)，因此window上原本就能够运行.NET的程序。省去了普通用户安装.NET framework的麻烦。

可是微软确定不会为window内置jdk的，缘由太简单了，若是window也都内置了jdk，而其余的linux，mac等操做系统也都进行内置，那么各个开发应用/游戏的厂商们，直接使用java开发就行了，而后开发出来的产品直接window/linux/mac全部系统平台上都通用，厂商们开心了，消费者也开心了，那这个时候，咱们为何还要使用window操做系统呢？反正对于普通消费者而言，使用应用或玩游戏都是没啥区别的。

（因此这也是为何java在pc端应用/游戏领域没人使用，而服务器端使用java的多，由于开发服务器的码农们搭配java环境很easy啊）

回想一下 window与Netscape的浏览器大战，若是使用浏览器就能干大部分事情，那么你们根本就不关心运行浏览器的操做系统是window仍是linux了。固然，如今互联网的流量/入口之争其实都是同一个道理。普通消费者哪里关心那么多，哪一个好用，哪一个便宜就用那个。

2014年11月12日，微软宣布将彻底开放.NET框架的源代码，并提供给Linux和OS X使用。

首先本博客当中很是清晰的表达了这个观点，什么跨平台不跨平台，适应各个平台/CPU的差别，这种脏活累活永远也得有人干，只是那些 去作虚拟机的人干了这种活，咱们这种纯粹写上层的人轻松了而已。

因此我觉的不少时候，能不能跨平台，除了技术问题，还要有商业缘由，甚至也有money的问题（毕竟开发各个平台的虚拟机也是不易）。就像 .NET理论上跨平台，可是不开源，几年前微软又不愿为.NET提供linux环境下的实现。那么天然没办法跨平台，可是这和技术无关。

java最初设计时，理论上就能够跨平台，可是那些苦逼的虚拟机开发者们还要去开发各个平台/cpu的虚拟机，这也不是一朝一夕之功。

微软如今可让.NET跨平台，一来大的形势变了（以前的操做系统卖的那么贵，如今win10均可以避免费了）,二来微软对.NET有控制权。而在java刚出来的时候，微软也支持java，也设计过微软版本的jvm。可是微软是想拥有对java技术体系的控制权，可是发现搞不过sun之类的，java不在它的控制之下，因此微软就开始搞本身的.NET平台了。

也许Java程序员听起来可能会以为惊讶，微软公司曾经是Java技术的铁杆支持者（也必须认可，与Sun公司争夺Java的控制权，令Java从跨平台技术变为绑定在Windows上的技术是微软公司的主要目的）。在Java语言诞生的初期，微软公司为了在IE3中支持Java Applets应用而开发了本身的Java虚拟机，虽然这款虚拟机只有Windows平台的版本，倒是当时Windows下性能最好的Java虚拟机。但好景不长，在1997年10月，Sun公司正式以侵犯商标、不正当竞争等罪名控告微软公司，在随后对微软公司的垄断调查之中，这款虚拟机也曾做为证据之一被呈送法庭。这场官司的结果是微软公司赔偿2000万美金给Sun公司（最终微软公司因垄断赔偿给Sun公司的总金额高达10亿美圆），承诺终止其Java虚拟机的发展，并逐步在产品中移除Java虚拟机相关功能。具备讽刺意味的是，到最后在Windows XP SP3中Java虚拟机被彻底抹去的时候，Sun公司却又处处登报但愿微软公司不要这样作。Windows XP高级产品经理Jim Cullinan称：“咱们花费了3年的时间和Sun打官司，当时他们试图阻止咱们在Windows中支持Java，如今咱们这样作了，可他们又在抱怨，这太具备讽刺意味了。”

这个故事告诉咱们一个道理：早知今日，何须当初呢。