免責聲明：這是我的個人觀點，并不代表雇主的觀點。

到目前為止，由于從Oracle遷移到Eclipse Foundation，每個人都知道我們需要將所有javax軟件包名稱重命名為其他名稱。

（供參考，請參閱附錄A）

目前基本上是討論，我們應該一次全部重命名，還是在更新API時分階段重命名（我相信我們現在應該全部重做并克服它），目前大多數人都認為我們會將所有javax重命名為jakarta 。

正在進行的另一討論是MicroProfile和Jakarata EE之間的關系。 我認為這兩個小組應該保持獨立，但要共同努力。 但是，如何工作仍在討論中。

將品牌與規范脫鉤。

目前，MicroProfile下的所有規范都使用名稱空間（或包名） org.eclipse.microprofile ，并且如前所述，Jakarta EE的建議是jakarta 。 兩者的groupId和artifactId類似，都包含“品牌”名稱（雅加達或MicroProfile）。

盡管這很有意義，并且大多數人都認為品牌應該在這兩種形式中都可見，但這將規范與品牌或分組結合在一起。

我的建議是從名稱空間和Maven工件中刪除品牌。 這意味著我們失去了一些品牌元素，但獲得了靈活性。 通過從規范中刪除分組，使該規范與某個總括項目相關的唯一事情是處理這些規范的工作組。 （從事此規范工作的人員）

例如，我們沒有重命名為org.eclipse.enterprise ，而是從javax重命名為jakarta 。 （只是一個例子）

因為我們可以在MicroProfile中進行重大更改，所以我們還從MicroProfile API中刪除了品牌，并將API重命名為org.eclipse.enterprise 。

MicroProfile和Jakarta EE關系。

目前，MicroProfile依賴于Jakarta EE（但并非相反）。 我建議您保持這種關系，所以只有這種關系可以解決。

MicroProfile是進行創新和試驗的好地方，但不是（必需）向后兼容的地方。 這使MicroProfile在創建新規范時可以快速移動。

但是，在某些時候，新的API確實已經成熟并且穩定，并且沒有添加任何新的主要功能，并且該API變得相當穩定。 在這一點上，也許值得一看，該工作是否應該移至Jakarta工作組，并從那時起就支持向后兼容。 MicroProfile傘仍然會依賴于它，但是以與依賴它從Jakarta EE提取的其他API相同的方式。

由于上述建議的命名方式，因此代碼不會更改，并且用戶可以繼續正常運行，唯一的不同是Jakarta EE具有新的API，并且該規范現在由另一個工作組和另一個Eclipse進程維護。

配置示例。

如果我們以config為例，則該API在MicroProfile下已經成熟，并且（可能）將工作組移至Jakarta。 在Jakarta或JSR下擁有另一個標準，可能不是一個好主意。 如果只有一個標準，則只有一個標準。 在我看來， JSR382應該退役，轉而使用遷移到雅加達的MicroProfile Config API。

未來分組。

一旦有了在品牌或分組之間移動API而不影響代碼和客戶的機制，我們就可以考慮其他分組，并且可能是從雅加達“淘汰”某些API的一種方式。

例如，如果我們在eclipse下創建一個新的分組，我們將其稱為ClassicProfile，就像MicroProfile一樣，我們可以讓ClassicProfile依賴于Jakarta，而不是相反。 然后，我們可以將不再需要在雅加達使用的舊API移到此配置文件中。 這意味著使用這些客戶端的客戶仍然可以在不更改代碼的情況下獲得它們，但這意味著我們可以節食Jakarta EE并使其更薄。

最后的想法

與大多數架構決策一樣，需要權衡取舍。 在這種情況下，品牌與可移植性。 但是我認為這樣做是值得的。 現在這樣做也很重要，我們有機會重命名當前的javax名稱空間，所以現在還是永遠不會。

附錄A

• 原始公告和此Twitter線程
• 來自Red Hat的Mark Little
• Ian Robinson，IBM的Kevin Sutter
• 來自Payara的Steve Millidge
• 來自Tomitribe的David Blevins
• 伊瓦爾·格里姆斯塔德
• 馬克·斯特魯伯特

翻譯自: https://www.javacodegeeks.com/2019/09/proposed-namespace-jakarta-ee.html

總結

以上是生活随笔為你收集整理的Jakarta EE的拟议命名空间的全部內容，希望文章能夠幫你解決所遇到的問題。

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