Jakarta EE：雲原生Java的新平臺

weixin_33766168發表於2018-05-03
Java
\

看新聞很累？看技術新聞更累？試試下載InfoQ手機客戶端，每天上下班路上聽新聞，有趣還有料！

\
\\

在今年的JAX大會上，Eclipse基金會的執行董事Mike Milinkovich專門介紹了新的Eclipse治理模型和Jakarta EE路線圖。新的治理模型基於近期對全球1800多名Java開發人員的調查情況，並將聚焦於提供對微服務、雲原生應用開發和加快版本釋出週期等特性的支援。

\\

在“Java創新的未來”（The Future of Java Innovation）分會上，Milinkovich首次展示了眾所期待的新Jakarta EE圖示。該圖示將用做新Jakarta EE網站的標識。

\\

a79893e210b1d295a292819ebcdad327.jpg

\\

Jakarta EE開發人員調查情況給出了三大關鍵領域：

\\
  • 更好地支援微服務；\\t
  • 與Kubernetes、Docker等的原生整合；\\t
  • 加速創新的步伐。\

最近，Milinkovich就Jakarta EE未來的發展問題接受了InfoQ的專訪。Milinkovich根據調查結果指出：

\\
\

上述目標是由社群為我們設立的，我們對此也有很好的共鳴。這些目標的實現，也是我們認為開發人員希望給出的正確場景之一。我們收到的反饋清楚地表明，開發人員與我們在這些目標上是步調一致的。

\
\\

Milinkovich進而指出：

\\
\

首先要記住的是，我們正在將Java EE全部遷移到Eclipse基金會，並重新命名為Jakarta EE品牌。Java EE將繼續存在，為其提供的支援將截至當前的版本級別。而未來的全部工作，都將在Jakarta EE品牌下開展。

\\

Java EE已被“財富”1000強企業在其基礎設施中的某處使用，並且全球目前已有數百萬的Java EE開發人員。因此，Java EE是一個非常重要的技術平臺，它驅動了大部分的企業系統。

\
\\

Milinkovich回憶了他在去年秋天Oracle將Java EE的所有權轉交給Eclipse基金會過程中的經歷，並介紹了Jakarta EE的前進道路：

\\
\

這是一次真正的旅程，最終，我們希望能夠形成約40個新專案、具有約300位新的Eclipse專案提交者。Java EE的所有專案上線並在Jakarta EE下重新命名，這其中的工作量非常大。

\\

為了實現對Jakarta EE倡議的管治，我們成立了一個Jakarta EE工作組。我們正在建立一種全新的規範流程，用於接管JCP在其中所發揮的角色，這同樣也將是一項十分重要的任務。我們還需要做一些工作，找出Jakarta EE品牌的合規程式。目前來看，我們的開局不錯。

\
\\

InfoQ：正如在新聞稿中所述，“該管理Jakarta EE程式碼庫的Eclipse頂級專案承諾將在2018年釋出兩個版本。” 這些版本是否存在著建議的時間表？

\\
\

Milinkovich：事實上稍為微妙。我們承諾在今年推出兩個版本，用於遷移到Eclipse的技術專案，分別稱為Eclipse GlassFish 5.1和5.2。Eclipse GlassFish 5.1將首次由Eclipse基金會交付所有的專案。對於所有專案的上線而言，GlassFish 5.1將成為一個主要的里程碑。考慮到要使用原先的Java EE TCK，該版本將被認證為Java EE 8相容。一旦釋出該版本之後，我們將進而推出5.2版，並稱之為Jakarta EE 8相容。

\\

因此，Jakarta EE規範的首個版本將與Java EE規範保持同一水平，並且目前看來，它們是相同或近乎相同。該過程只是遷移操作中的一部分，我們希望保持儘可能少的自由度。

\\

交付與Jakarta EE 8相容版本的重要意義，在於這表明我們將啟動並執行所有的規範流程，部署到位所有的認證計劃和法律協議，進而執行認證程式。

\
\\

InfoQ：這是否存在一個給定的時間表？

\\
\

Milinkovich：Eclipse GlassFish 5.1將於今年第三季度末推出，Eclipse GlassFish 5.2將於年底前通過Jakarta EE 8認證。

\
\\

InfoQ： 我們注意到，最近一輪的專案建議中包括GlassFish。

\\
\

Milinkovich： 是的，最近一批提案中包括了GlassFish，我們已經接近於完成。其實還有一點也是十分重要，但是對此人們尚未對此過多置評，那這就是開源所有TCK的專案建議。在我看來，一旦所有的TCK開源，這將成為一個非常重要的建議。

\
\\

InfoQ：Jakarta EE是基於Java EE 8的，我說得沒錯吧？

\\
\

Milinkovich： 我們必須根據品牌並基於規範，仔細考慮那些開源相關的事情。Jakarta EE和Java EE一樣，是一個依附於認證過程的品牌。因此，在宣告WebSphere已通過Java EE 8認證之前，它必須通過Java EE 8測試。

\\

類似的事情同樣適用於Jakarta EE。但需要了解的重要一點是，這不僅僅是從Eclipse基金會交付開原始碼。 而且也是為了支援那些在Jakarta EE品牌下的專有的和開源的獨立實現。

\\

並沒有任何供應商給出正式的通知。但就目前而言，我希望並期待有一天WebLogic釋出將被命名為Jakarta EE，並被認證為Jakarta EE 8相容。對於WebSphere、JBoss、TomEE等，同樣也是如此。

\
\\

InfoQ： Java EE、Jakarta EE和EE4J等命名容易讓人產生混淆。您能向我們的讀者解釋一下其間的差異嗎？

\\
\

Milinkovich：Java EE是當前定義Java EE的一組規範。Java EE是在JCP流程下完成的，並且為了達到當前的版本級別，還將繼續在市場上執行數年。因此，Java EE基本上已被置於“僅維護”模式。對於一位Java EE客戶，其軟體供應商將在未來幾年中繼續提供支援。

\\

Jakarta EE將成為這一持續推進的技術平臺的名稱。該技術的未來版本及其規格將以Jakarta EE的名稱和品牌釋出。我們將要建立一種類似的流程，用於驗證一個產品是否相容Jakarta EE。為此，產品必須要通過一系列的測試。這些測試的出發點與Java EE相同，因為它們是由Oracle提供給Eclipse基金會的驗證過程的組成部分。

\\

EE4J僅僅是Eclipse基金會的一個頂級專案名稱，大部分Jakarta EE專案執行於其中。通常情況下，我們很可能永遠不會在引用專案時以EE4J為名稱。未來，人們將稱自己是一位Jakarta EE開發人員。EE4J僅是一些組織工件，用於表示如何在Eclipse基金會上執行專案。

\\

Glassfish、Jersey、Grizzly、JAX-RS等技術的所有參考實現，都位於EE4J頂級專案之下。但是EE4J並非一個品牌，而僅僅是一個頂級專案的名稱。導致這種混亂的原因在於我們尚未選定品牌的名稱。所以，人們在一開始將其稱為EE4J，因為這是人們手頭唯一的命名。

\\

很不幸，這種混淆持續存在。這是不可避免的。希望隨著時間的推移，我們將不再聽到EE4J。

\
\\

InfoQ：Oracle是否將會繼續持有Java EE品牌？

\\
\

Milinkovich：Java EE和Java將仍然是Oracle持有的商標。如果你打算將某個專案以Java EE命名，那麼就必須要與Oracle商談如何使用該名稱。你可能已經看得了一些持有爭議性觀點的文章，它們對Oracle持批評態度，因為Oracle並未將Java EE命名轉交給Eclipse基金會。

\\

我想要指出兩點。第一，爭議是永遠不會發生的。人們從一開始就十分清楚，Java是Oracle的一個重要品牌，Oracle將會繼續擁有Java的品牌。如果你瞭解大公司和商標法的內容，你就會明白這是事情總是這樣的。

\\

第二，事實上，我們將這次重新命名看作是一件非常積極的事情，也是這項技術的一個絕佳機會。在許多開發人員的頭腦中，Java EE總是意味著十數年前在內部部署的應用伺服器。通過將該技術重新命名為Jakarta EE，我們有機會去改變這項技術能力在開發人員的思想中的印象。所以，我非常高興能做這次重新命名。我認為，這對我們而言是重塑這項技術的一個契機，可使該項技術在開發人員頭腦中重新定位，因而將具有更積極的前景。

\
\\

InfoQ： 這麼說，聚焦於雲原生特性絕對是一個好的出發點？

\\
\

Milinkovich：確切地說，我預計隨著技術的重點置於雲原生和微服務上，很快還將會出現響應式。我們將盡快將這些重要的技術趨勢加入到Jakarta中。這是一件十分新奇有趣的事情，因此我希望也確信，它們終將獲得通過。並且從今年現在開始，會出現一些願意嘗試Jakarta EE的開發人員。

\\

也許這些開發人員永遠都不會考慮去嘗試Java EE的某個新版本，因為在他們的印象中，Java EE並不會有助於問題的解決。所以我認為，對於Jakarta社群和技術而言，重新命名是一個很好的契機。

\
\\

InfoQ： 鑑於Java EE 8處於“僅維護”模式，Oracle是否將不會進一步發展Java EE？

\\
\

Milinkovich：是的。不會再有Java EE 9了。

\
\\

InfoQ：很多應用不能執行在Java SE 9上，例如Payara、GlassFish、OpenLiberty等。但這已經發生了一些變化。例如，Data Geekery jOOQ的支援專案已模組化，Speedment去年啟動了向Java 9的遷移過程。Jakarta EE最終是否會支援Java 9？

\\
\

Milinkovich： 我認為從某種程度上看，完全可以說Jakarta將支援Java 9。但很明顯，Java EE的整個生態系統尚未實現程式碼的模組化，進而可以使用Jigsaw，所以仍有許多工作需要推進。

\\

Java生態系統作為一個整體，必須要隨時關注平臺和語言的最新發展。我相信對Java 9的支援終將實現，但我並不清楚這將於何時發生，以及將在哪個發行版本中實現。它必須成為一個合理的優先事項，並且還有很多重要的事情需要完成。

\
\\

InfoQ：當然，相比起實現Java 9支援，當前的事項要更為優先。

\\
\

Milinkovich：部分原因在於對技術的採納。如果我們翻看一下調查結果，就會發現與Java 8的採納情況相比，採納Java 9（當前是新發布的Java 10）的比例微乎其微。因此，我認為在Java 8的支援過期後，將在幾年內看到更多的遷移。

\\

目前，要讓人們所具有的程式碼可完全適用於Jigsaw和模組化，還需要做大量的工作。所以，對Java 9的支援只是暫時擱置，直到迫不得已時才會啟動。

\\

同時，我認為壓力主要在於移植那些基於Java構建的工具和框架。一旦客戶和企業開始遷移基礎架構中的各項零零碎碎，從IDE到日誌記錄，這種將整個Java生態系統遷移到模組化無疑是一項艱鉅的任務。

\
\\

InfoQ：在JDK 11中去除了Java EE和CORBA模組（即JEP-310）。這是否會對Jakarta EE產生某種影響？

\\
\

Milinkovich：Java EE正在移交Eclipse基金會的過程中，其中將確保在SE和EE間給出絕對清晰的分離。部分洩漏到SE中的JTA規範，同樣也被拒之門外。所以，這只是一些背景清理工作，與其它所有的工作是並行發生。

\
\\

InfoQ： JDK已經採用新的“六個月釋出”週期。Jakarta EE是否也有必要採用同樣的釋出週期？

\\
\

Milinkovich：目前我們還不知道。依我個人的觀點，這並不反映社群中任何技術牽頭者的觀點，就是Jakarta EE完全沒有必要對Java SE亦步亦趨，去每隔六個月就推出一個新發布。

\\

在我看來，創新的速度和節奏，取決於我們需要採取什麼措施去實現雲本地和微服務，去實現響應式。我認為在這些創新中，只有相對較少的一部分是與Java SE平臺中的全新功能密切相關的。就此而言，我們會給出一個對我們自身有意義的釋出節奏，因為企業遷移到新版本Java發展的速度，肯定要滯後於Java的釋出速度。

\\

目前，我尚未看到將Jakarta EE的釋出節奏掛鉤到六個月週期以與Java SE亦步亦趨這一做法的可取之處，儘管我們可能終將看到。我可以構想每六個月交付一次這樣的場景，但這並不一定意味著我們每隔六個月就要推出一個新版本的Java。

\\

如果企業和雲端計算框架都沒有必要每隔六個月就轉向最新最好的Java版本，那麼我認為Jakarta EE也完全沒有任何必要這樣做。就像我曾說的那樣，這是完全是我的個人觀點。也許大家會看到，那些實際運作這些專案的技術人員會持完全不同的觀點。

\
\\

InfoQ：Eclipse基金會是否與雲原生計算基金會（CNCF）具有一定的工作聯絡？

\\
\

Milinkovich：公平起見，可以說是我們希望與CNCF建立工作聯絡。我們正在與CNCF就我們在構建物聯網中使用的一些技術上建立工作關係。我們的目標是確保Jakarta EE能以平臺形式，儘可能強壯地執行在Kubernetes和Docker生態系統上。這樣，我們就可以與CNCF開展合作，共同討論雙方的需求。

\\

我認為這對我們雙方而言都是一個很好的機會。很明顯，Kubernetes在工業界具有很好的發展勢頭，因為Kubernets不僅為人們提供了將工作負載從雲到雲服務提供商轉移出來的能力，而且也提供了從本地雲基礎設施轉移到公共雲基礎設施的能力。Kubernets為人們提供了很大的部署靈活性。

\\

與此同時，Java是企業中最重要的語言平臺。因此我認為，這兩種技術的緊密結合程度，不僅有助於雙方為企業採納雲端計算提供幫助，而且還充分地利用了數百萬開發人員的技能，並幫助他們將自身的技能推向該新技術領域。

\
\\

InfoQ：這是否意味著Eclipse基金會和CNCF需要以成員方式相互參與到對方的組織中？

\\
\

Milinkovich：我們可能會那樣做，但我們和CNCF都並非以收費服務（Pay-to-play）模式執行的基金會。這不是我們要做的事情。但我認為，這給出一種很好的姿態，使得我們雙方都可以公開表明，我們正開展合作，並具有很好的合作基礎。

\
\\

相關資源

\\

檢視英文原文： Cloud Native Java Has A New Home: Jakarta EE

相關文章