[[432394]]

正文

Oracle的一頓猛如虎操作，讓開發(fā)者徹底失去了Java EE。Eclipse基金會則自立門戶，另起爐灶開啟Jakarta EE項目。

對于Jakarta EE，從它的官網(wǎng)https://jakarta.ee能看到Eclipse基金會接手后共發(fā)布過三個版本：

• Jakarta EE 8：2019年9月發(fā)布，交接過來后發(fā)布的首個版本。特征總結(jié)為：

①：內(nèi)容完全同2017年8月發(fā)布的Java EE 8，無功能修改

②：對GAV坐標(biāo)做了變化，如老的javax.servlet:javax.servlet-api:4.01變更為jakarta.servlet:jakarta.servlet-api:4.02。這是本次版本升級的主要目的，把GAV坐標(biāo)先扭過來

③：命名空間依舊是javax，也就是說和Java EE 8是完全兼容的

• Jakarta EE 9：2020年11月發(fā)布。這一次，是阻斷式升級。特征總結(jié)為：

①：GAV同Jakarta EE 8

②：再無javax命名空間，而是全新的jakarta命名空間。如：javax.servlet.Servlet改為jakarta.servlet.Servlet

③：所有EE技術(shù)大版本號均升1。如：Servet 4.01升為Servlet 5.0.0，用以告知開發(fā)者其向下不兼容性

• Jakarta EE 9.1：2021年5月發(fā)布，增加JDK 11運行時支持。特征總結(jié)為：

①：不新增API，保持和Jakarta EE 9一樣

②：基線版本(最低編譯版本)依舊為JDK 8，但增加了JDK 11的運行環(huán)境

③：相關(guān)技術(shù)的版本號基本沒變化(只有少部分有小版本號+1情況)

總的來講，若想升級到Jakarta EE 9+版本，麻煩還是較大的。作為開發(fā)者的我們，該何去何從呢?本文就來分析下這給開發(fā)者帶來的轉(zhuǎn)變，佐證筆者為何得出結(jié)論：開發(fā)者已無理由再用Java EE。

升級到Jakarta EE有哪些轉(zhuǎn)變

當(dāng)然，這里指的是升級到Jakarta EE 9+版本。由于它是阻斷式升級，盤點清楚哪些轉(zhuǎn)變將非常重要。

名稱

舊名稱：Java EE;新名稱：Jakarta EE。

除了對品牌有影響(畢竟是全新品牌嘛)，對公司企業(yè)的影響不大，對開發(fā)者的影響也基本可忽略。

GAV坐標(biāo)

這里以Maven的GAV坐標(biāo)為例。

Java EE 8的GAV坐標(biāo)：

<dependency> 
    <groupId>javax</groupId> 
    <artifactId>javaee-api</artifactId> 
    <version>8.0.1</version> 
</dependency> 

 

Jakarta EE的GAV坐標(biāo)：

<dependency> 
    <groupId>jakarta.platform</groupId> 
    <artifactId>jakarta.jakartaee-api</artifactId> 
    <version>8.0.0</version> 
</dependency> 

 

解釋一下，也許你從未導(dǎo)入過甚至都沒見過這兩個API，它就是Java EE/Jakarta EE技術(shù)的集大成者：一個API包含所有EE技術(shù)，如servlet、ejb、el、validation等等。

對它陌生是因為絕大多數(shù)真實使用場景下，開發(fā)者并不會在一個project里面用全這些技術(shù)，而是按需導(dǎo)入獨立的API。

從截圖可以看到Jakarta EE 8的命名空間依舊是javax.*，但就像上面所描述的，若僅停在Jakarta EE 8的話，那便歲月靜好，一片和諧。但是，一旦升級到Jakarta EE 9+版本，景象就是這樣子的：

頂層命名空間改變!這就是接下來要說的內(nèi)容。

命名空間

如果說????兩項轉(zhuǎn)變對企業(yè)和開發(fā)者的影響微乎其微，那么命名空間的不兼容的影響將是巨大的，甚至致命的。這無異于直接是釜底抽薪呀，頂層包名都不一樣了，所有模塊均受到徹徹底底的影響。

命名空間不兼容的具體表現(xiàn)

“自古”以來不缺由于不向下兼容最終作死了的技術(shù)，那作為標(biāo)準(zhǔn)的Java企業(yè)級技術(shù)這次迎來這么大的阻斷式升級，會有哪些具體表現(xiàn)呢?我們可以從下面這幾個角度窺探一下

所有服務(wù)器需要重新編譯

Java EE服務(wù)器類型眾多，由于命名空間的變化，所有的服務(wù)器均需要重新編譯、發(fā)版。如：

• Eclipse的GlassFish：已適配。作為官方推薦的服務(wù)器，永遠最先適配
• Red Hat的WildFly：已適配。截止稿前已有preview版本適配了新命名空間
• Oracle的WebLogic：未適配。
• IBM的WebSphere：未適配。

下圖列出了截止稿前，已對Jakarta EE 9新命名空間做了適配的服務(wù)器(若是Jakarta EE 8舊命名空間的話遠不止這么多哦，證明不少服務(wù)器廠商還沒行動呢)：

Tips：你沒看錯，那個logo寫著中文字的是2002年就已創(chuàng)辦的中國公司：中創(chuàng)軟件商用中間件股份有限公司

Tomcat呢???嗯，Tomcat并非Java EE容器，而只是一個Servlet容器(Web容器)而已，所以不可能出現(xiàn)在這個列表里。但Apache Tomcat實現(xiàn)了四個 Jakarta EE規(guī)范：

• Jakarta Servlet
• Jakarta Standard Tag Library(JSTL)
• Jakarta WebSocket
• Jakarta Authentication

Apache Tomcat作為全球使用最廣泛(市占率超6成)的Web應(yīng)用服務(wù)器，響應(yīng)速度還是非?？斓模?/p>

簡而言之，Tomcat從10.x版本開始全面擁抱jakarta.*命名空間，9.x及以下版本用于保持對javax.*命名空間的支持。

企業(yè)自身代碼修改

企業(yè)自己的project代碼需要將import javax.*替換為import jakarta.*，修改并不復(fù)雜，看起來很簡單實則不簡單。

中大型企業(yè)的項目、服務(wù)成百上千個，你還會覺得簡單嗎?

有些代碼承接著巨大的流量不能有半點閃失，雖說僅僅只是改了“不影響邏輯”的代碼，但這帶來的風(fēng)險是企業(yè)必須付出更多的人力去規(guī)避的。

運維體系的修改

對于企業(yè)應(yīng)用來講，一般會保持定期升級應(yīng)用服務(wù)器的習(xí)慣。但由于存在新服務(wù)器不兼容老的應(yīng)用的問題，所以部署系統(tǒng)可能就需要兩套，成倍的增加了運維的成本。另外，使用兩套服務(wù)器的話，是否要繳納雙倍的費用給服務(wù)提供商呢?這也是個問題~

以上列出企業(yè)若要升級到新版Jakarta EE需要面臨的至少三大難題，如若不能低成本的“破解”，你覺得還有升級的必要嗎?

什么叫不用Java EE?

作為一個Java開發(fā)者，肯定聽過Java EE這個名詞，但大多數(shù)人都會回答沒用過，我并不詫異，因為你大概率一直在使用Spring/Spring Boot。如果說用過Spring Boot就等于用過Java EE，我覺得太過于牽強了，就像總不能說每個開車的司機都用過內(nèi)燃機、把玩過輪胎是一樣的道理。

如今在諸如Spring Boot這樣的框架包裝下，應(yīng)用層已經(jīng)找不到Java EE的蹤影了。所以“年輕的”面試者說沒用過Java EE并不會讓人覺得奇怪，畢竟在天朝互聯(lián)網(wǎng)企業(yè)中Spring已然成為實際的開發(fā)標(biāo)準(zhǔn)，且在持續(xù)侵蝕著Java EE的市占率，擁抱Spring Boot開發(fā)已是大勢所趨。

對于新一代開發(fā)者來講，Java EE已經(jīng)是古董級技術(shù)，隨著Spring技術(shù)棧的普及，已經(jīng)沒有什么理由再去使用Java EE/Jakarta EE技術(shù)，面向Spring編程會更高效。

估摸Oracle也是看形勢不對，索性就交出了Java EE順帶還混得個Eclipse基金會董事會席位，何樂而不為呢?但是，它不再讓繼續(xù)使用javax命名空間這行為實在太不講武德了，這件事引起了眾多開發(fā)者的反感。但，誰又惹得起呢，畢竟它乃是最擅長發(fā)律師函的Oracle呀!

Spring與Jakarta EE

Spring和Jakarta EE什么關(guān)系?

這個問題有點不太好回答，可以說它倆是競爭關(guān)系，也可以說Spring是基于Jakarta EE構(gòu)建的;可以說Jakarta EE是企業(yè)級開發(fā)的 官方標(biāo)準(zhǔn)，也可以說Spring是企業(yè)級開發(fā)的實際標(biāo)準(zhǔn)。它倆濃情蜜意這么多年，早已不可分割，所以新的Jakarta EE要想得到更多的覆蓋率，很重要的一點就是得看看Spring對它的支持程度，方可快速普及。

2021年9月1日，一年一度的Spring One大會在線上舉行，Spring項目擁有者Pivotal公司發(fā)布了Spring Framework 6.0以及Spring Boot 3.0的RaodMap，最重磅的變化莫過于這兩個

基于Java 17。話外音：不再支持Java 8、Java 11

基于Jakarta EE 9。話外音：不再支持Java EE，不再支持javax命名空間

以Spring現(xiàn)在的影響力和能力，筆者覺得它完全有能力自立門戶，不帶Jakarta EE一起玩了。但是Spring一直秉持著不重復(fù)造輪子的理念，成長于社區(qū)反哺于社區(qū)，一起維護更好的生態(tài)環(huán)境，這不就是對Java開發(fā)者最大的“負責(zé)”么。

對于開發(fā)者而言，只需保持對Spring/Spring Boot的熱度即可，至于Jakarta EE的發(fā)展、迭代，就讓它“淪落為”汽車的發(fā)動機吧，無需關(guān)注。

Tips：即使不是Spring框架，普通開發(fā)者(如果你不甘只做普通開發(fā)者，就...)也不會回到需要關(guān)心Java EE/Jakarta EE的年代，所以dark不必擔(dān)心

總結(jié)

雖然Oracle不講武德的操作，一度讓開發(fā)者非常的失望和憤怒。但隨著Spring的官宣：“帶著”Jakarta EE繼續(xù)前行，Javaer重拾信心，穩(wěn)步前行。

歷史的巨輪，浩浩蕩蕩的前進。有些是必然的趨勢，即使你現(xiàn)在還并不能接受，但這并不妨礙。Java 8再怎么堅挺，終究會迎來其生命的終點，這是不可阻擋的，比較人類需要進步，技術(shù)也是。

 

去Tomcat官網(wǎng)可以看到，它竟提供了應(yīng)用進行自動代碼轉(zhuǎn)換以支持jakarta的工具?；蛟S在不遠的將來我們可以看到各種奇yin巧技去搞兼容，又見那烏煙瘴氣的一幕。