其实这样的危机对于Java来说已经不是第一次了，在上个世纪90年代后期，也就是Java刚刚出现不长时间就遇到了第一次危机。当时微软为了跟SUN之间争夺Java的事实标准权，开发了自己特有的版本Visual J++，并与其VS系列开发套件结合在一起，还提供了专有的扩展API。这一系列行为都背离了SUN对于Java规范的要求。这一纷争导致SUN与微软之间刻薄地批评对方，并对簿公堂。最用在2001年以SUN胜出结束，这也让微软彻底离开了Java阵营，从此与Java无缘。在该事件之后，也确立了Java的使用原则，那就是SUN持有Java的标准权，无论哪个厂商，都必需遵守该标准。

　　在后来成立了的JCP组织，允许更多的厂商参与到Java的规范制定当中。JCP组织的出现，让IBM、Oracle很众多软件厂 商有机会参与到Java的发展当中，使Java得到了十足的发展。如果当时因为微软与SUN之争，导致Java标准分裂，就不会有今天的成就。

　　上一次危机已经过去10多年，今天新的危机有出现了。历史又一次重演。前几天VMWare与Google发表声明， 一起进军云计算领域。并将Java作为首选开发语言，着名的Java开源框架Spring作为首选开发模型。看起来这视乎在为已经10多岁的Java注入新生力量。

　　尽管Google是开源以及开放网络标准的坚定支持者。但是在谈到Java标准问题的时候，却说他们采用的是一个小于标准的纯Java路线。也就是说Google不会支持全部的Java标准。只会支持一部分。如果把Java标准比喻成大树的话，Google支持的部分可能是一个树枝、也可能只是一个树叶。这个说法对于Google来说，已经有过类似的历史。

　　在其开源Android平台上，采用的就是部分标准策略。在Android平台上，只支持Java基本语法和部分 API，并且必须采用Android特有的架构模式。更大的区别是，Android平台上的Java程序只是与标准Java程序在源代码级别兼容，编译结 果根本不一样，这导致Java的最大特点，也就是一次编译到处运行成为空话。

　　在Google与VMWare联手进军云计算的声明中，关于Java EE规范问题，Google说，他们只会支持该规范的一个子集。也许在不久的将来，大家将会看到一个被阉割过的Java EE版本。至于在云计算平台上将采用什么样的虚拟机问题，还没有确切的消息。很可能Google版本的Java EE与Android平台上的Java SE一样，只是一个拥有Java外表的Java。

　　有人也许会提出疑问，既然是这样，为什么Spring这样一个遵守Java规范的开源框架也会加入这一联盟，需要提醒大家的是，Spring的创始人本身也是一个Java EE规范的反对者，非常痛恨Java EE中的EJB以及重量级Web Service的人。其开发Spring的目的就是想改变Java EE的开发模式。

　　虽然现在还无法确定有多少企业打算吧他们的Java应用迁移到Google应用引擎下，但是从目前的数据来看，Google应用引擎社区注册用户只有不到5000人，这与数百万的Java开发者来说是一个个相当小的数字。

　　两个事件对以一下，会让人觉得惊人的类似。不同的地方就是Google的策略比较柔和，并没有像微软哪项想彻底的改变Java。但是，需要承认 的是，Google是一个非常强大的企业，强大到可以让一个Java 规范可用的子集变成一个事实上的标准子集。也就是说可让一个从大树上截取的树枝与大树处于同等的地位。

　　在这之前，Spring所做的也是类似的工作，其仅仅使用了Java EE的一个子集，但是没有Google做的深入彻底。如果Google对Java EE的做法与Android的手法类似，那么他就根本不必在乎谁持有Java的商标了，也不会在受任何限制，做到当时微软想做但是没有做到的事情。

　　这一切的后果就是导致Java规范的分裂。随着规范之间的距离越来越远，Java开发者将面对像C++开发者所面对的同样的问题，虽然采用的是 相同的程序语言，但是不同平台开发者之间几乎无法互相沟通和理解。