[[432394]]

正文

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

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

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

①：內容完全同2017年8月發布的Java EE 8，無功能修改

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

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

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

①：GAV同Jakarta EE 8

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

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

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

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

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

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

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

升級到Jakarta EE有哪些轉變

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

名稱

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

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

GAV坐標

這里以Maven的GAV坐標為例。

Java EE 8的GAV坐標：

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

 

Jakarta EE的GAV坐標：

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

 

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

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

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

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

命名空間

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

命名空間不兼容的具體表現

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

所有服務器需要重新編譯

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

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

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

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

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

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

Apache Tomcat作為全球使用最廣泛(市占率超6成)的Web應用服務器，響應速度還是非常快的：

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

企業自身代碼修改

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

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

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

運維體系的修改

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

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

什么叫不用Java EE?

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

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

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

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

Spring與Jakarta EE

Spring和Jakarta EE什么關系?

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

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

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

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

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

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

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

總結

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

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

 

去Tomcat官網可以看到，它竟提供了應用進行自動代碼轉換以支持jakarta的工具。或許在不遠的將來我們可以看到各種奇yin巧技去搞兼容，又見那烏煙瘴氣的一幕。