[[432394]]

正文

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

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

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

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

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

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

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

①：GAV同Jakarta EE 8

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

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

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

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

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

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

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

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

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

名稱

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

除了對(duì)品牌有影響(畢竟是全新品牌嘛)，對(duì)公司企業(yè)的影響不大，對(duì)開發(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)入過甚至都沒見過這兩個(gè)API，它就是Java EE/Jakarta EE技術(shù)的集大成者：一個(gè)API包含所有EE技術(shù)，如servlet、ejb、el、validation等等。

對(duì)它陌生是因?yàn)榻^大多數(shù)真實(shí)使用場景下，開發(fā)者并不會(huì)在一個(gè)project里面用全這些技術(shù)，而是按需導(dǎo)入獨(dú)立的API。

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

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

命名空間

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

運(yùn)維體系的修改

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

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

什么叫不用Java EE?

作為一個(gè)Java開發(fā)者，肯定聽過Java EE這個(gè)名詞，但大多數(shù)人都會(huì)回答沒用過，我并不詫異，因?yàn)槟愦蟾怕室恢痹谑褂肧pring/Spring Boot。如果說用過Spring Boot就等于用過Java EE，我覺得太過于牽強(qiáng)了，就像總不能說每個(gè)開車的司機(jī)都用過內(nèi)燃機(jī)、把玩過輪胎是一樣的道理。

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

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

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

Spring與Jakarta EE

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

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

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

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

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

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

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

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

總結(jié)

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

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

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