如果您錯過了新聞， Oracle將向Eclipse基金會捐贈Java EE規范 。 這項決策在規范過程中經歷了相當長時間的休眠，在此過程中，人們理所當然地懷疑Oracle對Java EE失去了戰略興趣。 起初，Java EE和更廣泛的Java社區很好地滿足了捐贈規范的決定。 在沒有Oracle減慢流程速度的情況下，Java EE涉及人員可以再次嘗試關閉非標準化的API。 直到今天，由于Oracle和Eclipse基金會對捐贈的一些細節仍存在分歧，因此捐贈過程尚未完成。

在推翻所有知識產權的同時，Oracle在規范的新家中使用其Java品牌的方式也不太慷慨。 Java EE當然包含Oracle擁有的開放源代碼但受商標保護的平臺的名稱。 這在法律上帶來了一個問題：如果您授權第三方使用您的品牌名稱，那么您就產生了將來限制其使用的權利。 更糟的是，在涉及與品牌有關的訴訟時，您可能會削弱自己在法庭上的地位。 甲骨文和谷歌在Java許可問題上爭論了多年，因此人們可以預料到商標將是一個困難的討論點。 而且，在不假裝對國際商標法了解太多的情況下，更多參與其中的人告訴我，“使用它或失去它”對于理解此類分歧的總體座右銘來說已經足夠好了。 因此，首先將規范從Java EE重命名為Jakarta EE，以避免利益沖突。

但是，新成立的雅加達EE社區真正令人震驚的事情尚未到來。 經過幾個月的討論，有關捐贈的形式，Eclipse基金會了解到，它既不能擁有托管Java EE中定義的API的當前javax名稱空間的所有權。 相反，現在計劃為所有捐贈的API休眠此名稱空間。 因此，應該在Jakarta EE的規范過程中創建的任何新API都應托管在新的命名空間中，以避免侵犯Oracle的商標。

在這一點上，弄清楚這意味著什么很重要。 不禁止Jakarta EE和Eclipse Foundation使用javax命名空間或實現其API。 當前存在的API都不會被刪除。 但是，在新形成的Jakarta EE規范過程中創建或更新的任何API都將需要存在于一個新的名稱空間中，該名稱空間很可能模仿現有的名稱空間，但以jakarta作為其前綴而不是javax。 例如，如果要將新方法添加到
javax.servlet.Servlet接口，該servlet規范的下一版本將需要發布一個名為
jakarta.servlet.Servlet而不是將此方法添加到現有API。

我不是Java EE用戶，我為什么要關心？

正式地，大多數人都知道Java平臺分為兩個部分。 第一部分是Java SE，其中所有API均在帶有java前綴的軟件包中定義。 除此之外，Java EE的指定E X內java的X命名空間撫育的API。 這些API并不意味著特定的實現，而僅定義由Java EE兼容組件的不同供應商實現的行為。

在這種情況下，Java EE是幾個互不依賴的API規范的統稱。 例如，Java消息傳遞規范（JMS）定義了一個用于與消息隊列進行交互的API，而Java servlet規范定義了一個用于將調用分派到Web服務器的API。 實際上，據我所知，沒有Java EE應用程序運行時實現了Java EE規范過程中定義的所有API。 一些Java框架甚至只專注于實現一個規范。 例如，Jetty Web服務器僅實現Java servlet規范。 因此，如果您通過Spring Boot使用Jetty，即使您沒有直接與規范交互或認為自己是Java EE用戶，您還是Java EE的正式用戶。

盡管有這種形式上的區別，即使您只編寫了普通Java而沒有包括任何外部依賴關系，您也可能會遇到Java EE及其javax名稱空間。 這是因為選定的Java EE API與JVM的標準映像捆綁在一起。 除了API之外，JVM還附帶了該API的默認實現，以使用戶能夠輕松解決常見任務。 例如，JAXP是Java EE規范，它定義了用于在Java中處理XML的API。 XML處理是一項常見的任務，尤其是在面向企業的Java平臺上，將XML包含在內是一個合理的選擇。 對于JAXP，其假定的通用用法在今天仍然是事實，但是其他與JVM捆綁在一起的Java EE規范的老化程度也不盡相同。 例如，對于大多數Java開發人員而言，SOAP消息傳遞不再是首選，因此JVM捆綁的JAX-WS實現已成為大多數用戶的負擔。 為了減少JVM的占用空間并在Java 9中引入Java模塊系統，一些Java EE API已移至已棄用的模塊，這些模塊計劃在將來的版本中刪除。 當然，這并不意味著模塊的API本身已被棄用。 JAX-WS仍然活躍并且被許多人積極使用。 但是，由于不贊成使用此模塊，希望在將來的Java版本中繼續使用JAX-WS的人員必須將其作為顯式依賴項添加。

在我們在虛擬化硬件上運行微服務的時代，減少JVM的占用已成為發展JVM的明顯目標。 但是，從基本JVM映像中刪除Java EE API的另一個好處是。 通過要求用戶包括對Java EE API的顯式依賴，升級Java運行時和Java EE不再捆綁在一起。 在Java 8之前，管理此類版本依賴性一直很乏味。 如果您不控制將應用程序部署到的JVM的確切版本，則尤其如此。 在Java 8之前，JVM僅允許通過將jar文件放入JVM的擴展文件夾中來覆蓋隱式的Java EE依賴關系。 但是，當您與也會受到影響的其他Java進程共享JVM安裝時，這當然是有問題的。 另外，仍然需要對正在使用的JVM安裝進行控制。 為了解決此問題，盡管繼續進行按需捆綁，但Java模塊系統默認不再解決不推薦使用的Java EE模塊，這使得可以在JVM中包含顯式版本，同時還提供了一種激活舊版兼容性的簡單方法。

為了使事情變得更加復雜，一小部分Java EE API變成了不允許簡單分離的Java SE。 例如，JDBC規范分為“客戶端”和“服務器端”需求，其中前者正式屬于Java SE，而后者則屬于Java EE。 這種區別來自最初的Java哲學，在Java哲學中，Java SE用于面向用戶的桌面應用程序，而Java EE用于多個并發用戶使用的服務器應用程序。 本著這種精神，例如，JDBC連接接口是在java.sql包中定義的。 畢竟，桌面用戶當然可能要連接到數據庫。 另一方面，由于僅將連接池視為多線程服務器應用程序的要求，因此在javax.sql包中定義了JDBC DataSource接口。 從今天的角度來看，這種分離當然不再有意義，但是名稱空間和形式上的區別直到今天仍然存在。

當然，在由OpenJDK項目管理的Java SE和現在由Eclipse基金會管理的Jakarta EE內，分別使JDBC API演變是沒有意義的。 因此，并不是將Java EE規范的所有部分都捐贈給了Eclipse，因此將為JDBC API保留javax.sql命名空間，該JDBC API現在被認為僅是Java SE的一部分。 保留此類API的其他示例是JMX API，它嚴重依賴于本機JVM支持。 當然，所有一直被認為是Java SE一部分的其他API（例如也以Java擴展名稱空間結尾的Swing API）將保留在其原始包中。

向后兼容性呢？

要記住的重要一點是，無論是現在還是將來，目前都不會消失現有的javax API。 我個人也希望Jakarta EE現在包含的規范能夠在未來很多年內支持javax命名空間。 實際上，對于大多數Java EE實現而言，處理多個名稱空間并不是什么新鮮事物，但始終是一個重要的主題。 例如，當用JPA規范定義的注釋逐步替換其注釋時，Hibernate庫已經成功完成了類似的遷移。 在另一個示例中，Spring框架與其本機注釋并行地支持Java EE CDI規范。 這樣做，例如，可以通過使用
javax.inject.Inject注釋或Spring的本機Autowired注釋。 一旦將Inject批注轉移到jakarta包中，我將期望Spring框架同時支持Java EE和Jakarta EE命名空間，正如我也期望Java企業API的其他實現者支持它一樣。

隨著Jakarta EE成為Java EE的繼任者，我不希望這種支持的實現或維護成本太高，因為應用程序服務器供應商可以簡單地實現委托給現已過時的Java EE API的Jakarta EE包裝器類。 例如，通過定義類似于以下內容的包裝器類，可以在內部將Java EE servlet視為Jakarta EE servlet：

public class LegacyServlet implements jakarta.servlet.Servlet { private final javax.servlet.Servlet delegate; public LegacyServlet(javax.servlet.Servlet delegate) { this .delegate = delegate; } @Override public void service(jakarta.servlet.ServletRequest req, jakarta.servlet.ServletResponse resp) { delegate.service( new LegacyServletRequest(req), new LegacyServletResponse(resp)); } }

如果Jakarta EE的目標是（邏輯）向后兼容當前規范和API，那么這應該相當簡單。 如果遵守此原則，則還要求API的用戶僅更新到Jakarta命名空間，以防他們想使用已經需要更改代碼的新功能。 因此，我希望更改后的名稱空間不會對未來的Jakarta EE用戶產生太大影響，而主要是那些實現其API的人的關注。 回顧過去對Java平臺的其他更根本的變化，當引入Java模塊系統時，也是如此，例如，Java模塊系統主要涉及庫和框架開發人員，而很少涉及Java的最終用戶。

當然，對這兩種名稱空間的支持永遠不會通用，尤其是從長遠來看，因此，Java EE API的用戶最終將需要對過渡做出反應。 鑒于該規范保留了其API的二進制兼容性，但不包括名稱空間前綴的更改，因此，我確實認為移植軟件應該易于克服，甚至可以自動化。 任何Java類都在每個類文件的常量池中引用其導入的類型。 對于使用新的jakarta前綴來修補工件的所有常量池中的所有相關類型引用的工具而言，這將是微不足道的。 這樣做，Java EE的舊用戶可以避免在被動維護下對其應用程序進行源代碼更改，而僅在編譯后應用此類更改，甚至在部署期間修補工件。

是什么推動了Oracle？

我當然是軟件顧問，而不是國際商標管轄權的專家。 我對Oracle的決策過程也沒有任何見解。 因此，請把這最后一部分當作有根據的推測，加上我的個人觀點，而不是事實摘要。

Java社區中的一些聲音當前正在指責Oracle通過限制Javax名稱空間的使用來違反Java及其用戶的利益。 在Eclipse基金會中也進行了激烈的辯論，以至于有人建議以這種方式捐贈Java EE，因為它與組織的目標和價值不兼容。

鑒于這一更改確實對Java用戶帶來了巨大的工作量，因此當然可以很快得出這一觀點。 但是，我無法想象Oracle會輕率地做出這個決定。 甲骨文正在并且一直在Java平臺上進行大量投資-Java至今還沒有像現在這樣活躍-但是它也改變了其戰略定位。 對我而言，甲骨文在進行這些投資時并不“關心” Java社區的想法根本不合適。

那么，我認為該決定的動機是什么？ 對我來說，限制與Java EE無關，而是關于Oracle保護其對Java SE的興趣。 歸根結底，甲骨文正在向Java投資以獲利。 通過允許使用其商標，甲骨文將放棄對其品牌的控制權，從而使這一目標陷入危險。 當然，Oracle依靠Java來開發自己的產品并因此維護它。 但是與此同時，該公司試圖創建一種戰略模型，以證明為數百名從事Java工作的全職高素質員工提供資金。

顯然，甲骨文正在推動銷售云解決方案，并且鑒于該公司除了實力雄厚之外，目前在運行時和數據庫方面的主導地位，我相信他們在該領域獲得重要市場份額的機會比許多人預期的要好。 Oracle在核心平臺上取得成功的另一個計劃是對Graal VM及其編譯器的投資，這當然也為Java語言在資源受限的環境（如容器內）中提供了更廣泛的應用范圍。

但是，盡管在某些領域進行投資，Oracle肯定也在尋找削減成本的方法，并終止不再具有戰略意義或盈利能力不足的企業。 盡管讓用戶（包括我自己）感到沮喪的是， 像Java飛行記錄器這樣的成功的項目團隊被解雇了 ，但考慮到絕大多數Java開發人員都不需要這種工具，這是有道理的。 我相信Java EE既不適合Oracle的計劃，也不適合該平臺的成本概況，并且懷有類似的信念。

有鑒于此，Oracle可能考慮了放棄該規范與將其捐贈給其他人維護之間的權衡。 盡管捐贈Java EE的選擇似乎是沒有成本的，但是Oracle無疑會為此做出冒險。 通過允許競爭的組織繼續他們在Java EE中的努力，這些努力還可以增強他們在Java SE領域與Oracle競爭的能力。 在Red Head和IBM參與了云解決方案市場競爭的那些組織中，尤其如此。 通過保護其商標權，Oracle的目標僅僅是降低競爭對手使用Java EE爭奪Java SE市場份額的風險。 公平地說，Oracle為Eclipse基礎提供了一種繼續使用javax名稱空間的方法。 但是，這將需要基金會將自身限制為將其產品與Java SE認證的JVM實現捆綁在一起，而不是例如將其自己的IBM捐贈的OpenJ9捆綁在一起 。 這樣做，盡管Eclipse使用了javax名稱空間，Oracle仍將保留對其品牌的足夠控制權，但是同時，簽署如此廣泛的協議也不符合該基金會的利益是可以理解的。 只是不意味著如此，因此，甚至有人可能會認為Eclipse首先是接受Java EE捐贈的錯誤選擇。

接下來是什么？

在開源社區中，我們經常大聲討論我們的工作資金不足。 而且，盡管缺乏盈利能力對于單個開發人員來說難以解決，但對于大型公司（無論是Oracle還是當前討論中涉及的任何其他公司）而言，這當然也是一個問題。 在我看來，通過Oracle捐贈Java EE的知識產權，Java社區已經移交給了該規范的最重要的價值，我們應該集中精力處理已有的東西，而不要因附加的字符串而過度分散注意力。 就個人而言，如果甲骨文失去了對Java品牌的興趣而不是站穩了腳跟，我將更加擔心Java的未來。

對于Jakarta EE，我都不認為即將到來的名稱空間遷移是規范面臨的最大問題。 甚至在最近的停滯期之前，許多開發人員就對Java EE的灰塵感到沮喪。 我認為，問題是該過程的一部分。 實際上，Java EE規范通常來自領先框架的實現。 如果另一個框架想要重新發明如何通過更好的API解決相同的問題，則需要不斷批評該框架不遵守該標準。 盡管事實是該標準通常只是先前最佳實踐的快照，但所有這些。 因此，我希望Jakarta EE可以專注于其發展，而不是過多地保留其過去。 有了引人注目的最先進的API，如果它使我免于實現最小改動的迭代，那么我就不必擔心調整代碼。
jakarta.servlet.Servlet API。

翻譯自: https://www.javacodegeeks.com/2019/05/jakarta-ee-without-javax-world-wont-end-time-either.html

總結

以上是生活随笔為你收集整理的没有Javax的Jakarta EE：这次世界也不会结束的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。