正文
Oracle的一頓猛如虎操作,讓開發(fā)者徹底失去了Java EE。Eclipse基金會則自立門戶,另起爐灶開啟Jakarta EE項(xiàng)目。
對于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運(yùn)行時支持。特征總結(jié)為:
①:不新增API,保持和Jakarta EE 9一樣
②:基線版本(最低編譯版本)依舊為JDK 8,但增加了JDK 11的運(yùn)行環(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+版本。由于它是阻斷式升級,盤點(diǎn)清楚哪些轉(zhuǎn)變將非常重要。
名稱
舊名稱:Java EE;新名稱:Jakarta EE。
除了對品牌有影響(畢竟是全新品牌嘛),對公司企業(yè)的影響不大,對開發(fā)者的影響也基本可忽略。
GAV坐標(biāo)
這里以Maven的GAV坐標(biāo)為例。
Java EE 8的GAV坐標(biāo):
-
-
javax -
javaee-api -
8.0.1
Jakarta EE的GAV坐標(biāo):
-
-
jakarta.platform -
jakarta.jakartaee-api -
8.0.0
解釋一下,也許你從未導(dǎo)入過甚至都沒見過這兩個API,它就是Java EE/Jakarta EE技術(shù)的集大成者:一個API包含所有EE技術(shù),如servlet、ejb、el、validation等等。
對它陌生是因?yàn)榻^大多數(shù)真實(shí)使用場景下,開發(fā)者并不會在一個project里面用全這些技術(shù),而是按需導(dǎo)入獨(dú)立的API。
從截圖可以看到Jakarta EE 8的命名空間依舊是javax.*,但就像上面所描述的,若僅停在Jakarta EE 8的話,那便歲月靜好,一片和諧。但是,一旦升級到Jakarta EE 9+版本,景象就是這樣子的:
頂層命名空間改變!這就是接下來要說的內(nèi)容。
命名空間
如果說????兩項(xiàng)轉(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ù)器,永遠(yuǎn)最先適配
- Red Hat的WildFly:已適配。截止稿前已有preview版本適配了新命名空間
- Oracle的WebLogic:未適配。
- IBM的WebSphere:未適配。
下圖列出了截止稿前,已對Jakarta EE 9新命名空間做了適配的服務(wù)器(若是Jakarta EE 8舊命名空間的話遠(yuǎn)不止這么多哦,證明不少服務(wù)器廠商還沒行動呢):
Tips:你沒看錯,那個logo寫著中文字的是2002年就已創(chuàng)辦的中國公司:中創(chuàng)軟件商用中間件股份有限公司
Tomcat呢???嗯,Tomcat并非Java EE容器,而只是一個Servlet容器(Web容器)而已,所以不可能出現(xiàn)在這個列表里。但Apache Tomcat實(shí)現(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)速度還是非常快的:
簡而言之,Tomcat從10.x版本開始全面擁抱jakarta.*命名空間,9.x及以下版本用于保持對javax.*命名空間的支持。
企業(yè)自身代碼修改
企業(yè)自己的project代碼需要將import javax.*替換為import jakarta.*,修改并不復(fù)雜,看起來很簡單實(shí)則不簡單。
中大型企業(yè)的項(xiàng)目、服務(wù)成百上千個,你還會覺得簡單嗎?
有些代碼承接著巨大的流量不能有半點(diǎn)閃失,雖說僅僅只是改了“不影響邏輯”的代碼,但這帶來的風(fēng)險是企業(yè)必須付出更多的人力去規(guī)避的。
運(yùn)維體系的修改
對于企業(yè)應(yīng)用來講,一般會保持定期升級應(yīng)用服務(wù)器的習(xí)慣。但由于存在新服務(wù)器不兼容老的應(yīng)用的問題,所以部署系統(tǒng)可能就需要兩套,成倍的增加了運(yùn)維的成本。另外,使用兩套服務(wù)器的話,是否要繳納雙倍的費(fèi)用給服務(wù)提供商呢?這也是個問題~
以上列出企業(yè)若要升級到新版Jakarta EE需要面臨的至少三大難題,如若不能低成本的“破解”,你覺得還有升級的必要嗎?
什么叫不用Java EE?
作為一個Java開發(fā)者,肯定聽過Java EE這個名詞,但大多數(shù)人都會回答沒用過,我并不詫異,因?yàn)槟愦蟾怕室恢痹谑褂肧pring/Spring Boot。如果說用過Spring Boot就等于用過Java EE,我覺得太過于牽強(qiáng)了,就像總不能說每個開車的司機(jī)都用過內(nèi)燃機(jī)、把玩過輪胎是一樣的道理。
如今在諸如Spring Boot這樣的框架包裝下,應(yīng)用層已經(jīng)找不到Java EE的蹤影了。所以“年輕的”面試者說沒用過Java EE并不會讓人覺得奇怪,畢竟在天朝互聯(lián)網(wǎng)企業(yè)中Spring已然成為實(shí)際的開發(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命名空間這行為實(shí)在太不講武德了,這件事引起了眾多開發(fā)者的反感。但,誰又惹得起呢,畢竟它乃是最擅長發(fā)律師函的Oracle呀!
Spring與Jakarta EE
Spring和Jakarta EE什么關(guān)系?
這個問題有點(diǎn)不太好回答,可以說它倆是競爭關(guān)系,也可以說Spring是基于Jakarta EE構(gòu)建的;可以說Jakarta EE是企業(yè)級開發(fā)的 官方標(biāo)準(zhǔn),也可以說Spring是企業(yè)級開發(fā)的實(shí)際標(biāo)準(zhǔn)。它倆濃情蜜意這么多年,早已不可分割,所以新的Jakarta EE要想得到更多的覆蓋率,很重要的一點(diǎn)就是得看看Spring對它的支持程度,方可快速普及。
2021年9月1日,一年一度的Spring One大會在線上舉行,Spring項(xiàng)目擁有者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ū),一起維護(hù)更好的生態(tài)環(huán)境,這不就是對Java開發(fā)者最大的“負(fù)責(zé)”么。
對于開發(fā)者而言,只需保持對Spring/Spring Boot的熱度即可,至于Jakarta EE的發(fā)展、迭代,就讓它“淪落為”汽車的發(fā)動機(jī)吧,無需關(guān)注。
Tips:即使不是Spring框架,普通開發(fā)者(如果你不甘只做普通開發(fā)者,就...)也不會回到需要關(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)挺,終究會迎來其生命的終點(diǎn),這是不可阻擋的,比較人類需要進(jìn)步,技術(shù)也是。
去Tomcat官網(wǎng)可以看到,它竟提供了應(yīng)用進(jìn)行自動代碼轉(zhuǎn)換以支持jakarta的工具。或許在不遠(yuǎn)的將來我們可以看到各種奇yin巧技去搞兼容,又見那烏煙瘴氣的一幕。
原文鏈接:https://mp.weixin.qq.com/s/bWVTBRwERXV2adzL00LT-A