鉴于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将真正检验甲骨文管理一个复杂的开源项目的水平如何，这是许多代码贡献者的利益彼此冲突的一个项目。
