本文主要是介绍Java规范第二次面临分裂危机,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
【51CTO观察】其实这样的危机对于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注入新生力量。但是51CTO也敏锐的发现,VMWare与Google一系列动作之后,也为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++开发者所面对的同样的问题,虽然采用的是相同的程序语言,但是不同平台开发者之间几乎无法互相沟通和理解。
这篇关于Java规范第二次面临分裂危机的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!