鑒于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將真正檢驗甲骨文管理一個復雜的開源項目的水平如何，這是許多代碼貢獻者的利益彼此沖突的一個項目。