Java 8整装待发 图谋云计算

日期: 2011-08-08 翻译:布加迪 来源:TechTarget中国 英文

  鉴于Java 7 SE(标准版)现已正式发布,甲骨文和Java社区进程组织(JCP)的成员们已开始仔细考虑为这种编程语言的下一个版本Java SE 8添加什么功能特性。为这个新版本提上议程的工作是:设计面向云计算的Java。

  Mark Little是红帽公司中间件事业部的高级工程主管,也是红帽针对JCP的主要联络官。他说:“Java 8旨在为云计算作好准备,面向更广泛的部署领域。”他强调,为了不至于进一步推迟版本的发布,甲骨文撤掉了原计划为Java 7添加的许多高级功能特性。那些功能特性很有可能添加到Java 8中。

  Little表示,结果将证明,那些功能特性中至少有两项会非常有助于让下一个版本的Java为云计算的大规模部署作好准备。一项是多租户功能,即Java虚拟机(JVM)安全地运行多个应用程序的功能。另一项是模块功能,即把Java开发工具包(JDK)重新组织成一套定义清晰但又相互关联的模块。

  Little说:“如果Java想在云计算环境成为主导者,那么模块功能和JVM里面真正的多租户功能对Java 8来说很重要。”

  Little表示,模块功能是红帽最希望出现在Java 8中的一项特性。模块功能将减小大多数Java部署环境的规模,因为不是所有的部署环境都需要Java的全部核心库。该功能还有望帮助开发人员更容易与Java进行交互,让他们只要使用所需的部分,而不是设法应对整个代码库。

  模块功能还有助于开发人员解决Little所说的“类装入器难题”(classloader hell)这个问题。

  某个Java程序访问多个Java存档(JAR)即常用例程的组合时,开发人员就会遇到类装入器难题。应用程序可能会使用来自某个JAR的一个类,它实际上需要该类驻留在另一个JAR中的不同版本。或者,应用程序可能在使用由另一个程序使用的JAR;一旦那另一个程序终止,JAR就被移除,导致第一个应用程序停止运行。

  Little说:“为了让模块可以随意换进换出,又不破坏整个环境,就需要在JVM中同样给予支持。”

  Project Jigsaw这一项计划就致力于实现这个目标。Sun公司掌控Java(Sun在2010年被甲骨文收购)时,这家公司的工程师青睐Jigsaw,而不是另一种方案:开放服务网关计划(OSGi),后者由OSGI组织监管。

  Little表示,Project Jigsaw原本为Java 7而生,不过它在2010年被暂停,目的是为了在2011年之前交付Java。不过Little预测,来自Jigsaw或OSGi的工作成果都不会添加到Java 8中。他说:“Java SE 8中会存在一定的模块功能。”

  除了模块功能外,Java 8可能还有多租户功能,即通过一个JVM,安全地运行多个应用程序的功能。

  这类功能对于Java应用于云计算环境来说必不可少;在云计算环境下,多个有关方共享同一个基础设施。

  不过,如今Java EE(企业版)为解决这个问题提供了一种变通方法。Little说:“如果JVM本身不提供多租户功能,那么我们所能进行的操作非常有限,以免整个环境可能因同一个JVM中的破坏性租户而受到破坏。”

  Little主张为JVM添加这项功能:为每个应用程序提供各自的内存空间,即分区(zone)。这样一来,“破坏性应用程序就无法溢出,进入到你为在同一个JVM中运行的另一个应用程序留出的内存空间。”

  推崇这个想法的不是只有Little一人。

  弗雷斯特研究公司的分析师John Rymer也认为:“为JVM添加多租户功能很重要。如今,每家开发商都必须各自想办法来对应用服务器进行虚拟化。”

  把多租户功能添加到JVM中将减轻每一种独特方案所带来的培训压力。这不但可以缓解被开发商锁定的现象,“还让开发商可以将更多的精力投入到确保稳定性和性能上,而不是基本功能上,”Rymer如是说。

  许多人长期以来支持添加到Java中的另一项功能是闭包(closure),即在一个函数里面建立另一个函数,让它们共享变量的功能。闭包将有助于跨多个处理器核心,更高效地运行Java。

  尽管甲骨文的首席Java架构师一直满怀热情地要将闭包功能添加到Java中,但他并不认为建议的实现技术已为Java 7作好了准备。闭包功能要不要添加到Java 8中会开始引发新的一场争论。

  如果添加闭包功能,Java将因而与已经添加了这项功能的其他语言(如JavaScript和Scala)处于不相上下的水平。

  Scala开发者兼Scala工具开发商Typesafe的联合创始人Martin Odersky夸口说:“Java在闭包功能方面的工作似乎与我们已经在Scala中拥有的闭包功能相类似,但存在更多的限制。”

  除了技术本身外,许多人在密切关注甲骨文今后会如何监管Java 8。

  甲骨文还没有为Java 8版本制定一份官方时间表,不过JCP组织的成员们似乎渴望避免为下一个版本再次等待漫长的间隔期,已在非官方场合表态会在2012年年底之前发。Little说:“我们不想在Java 7和Java 8之间再等上个四五年。”

  至于如何处理Java方面,甲骨文本身一直在遭到越来越严格的盘查。多方指出,甲骨文交付的Java 7存在已知的软件缺陷。

  Little说:“有时我认为甲骨文说的话模棱两可。有时,我访谈过的甲骨文人员确实想把事情做好,竭力避免像对待闭源项目那样运营开源项目。”

  然而有时,Little却发现甲骨文的做法有悖于这些原则。他提到了2010年甲骨文在没有征求意见的情况下,改变了维护开源版JDK的OpenJDK项目的治理细则。结果,红帽失去了其在指导委员会的席位,“尽管明摆着我们贡献了那么多的代码,”Little愤愤不平地说。

  Little说:“我们参与了好多个开源项目。甲骨文的整个处理方法对我们来说不是显得非常符合开源原则。”甲骨文拒绝就本文发表评论。

  从许多方面来看,Java 8将真正检验甲骨文管理一个复杂的开源项目的水平如何,这是许多代码贡献者的利益彼此冲突的一个项目。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐