jakarta ee

免責(zé)聲明：這是我的個(gè)人觀點(diǎn)，并不代表雇主的觀點(diǎn)。

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

（供參考，請(qǐng)參閱附錄A）

目前，討論基本上是，我們應(yīng)該一次全部重命名，還是在更新API時(shí)分階段進(jìn)行（我相信我們現(xiàn)在應(yīng)該全部完成并結(jié)束），目前大多數(shù)人都認(rèn)為我們會(huì)將所有javax重命名為jakarta 。

正在進(jìn)行的另一討論是MicroProfile和Jakarata EE之間的關(guān)系。 我相信這兩個(gè)小組應(yīng)該保持獨(dú)立，但要共同努力。 但是，如何工作仍在討論中。

將品牌與規(guī)格分離。

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

盡管這很有意義，并且大多數(shù)人都認(rèn)為品牌應(yīng)該在這兩種形式中都可見(jiàn)，但這將規(guī)范與品牌或分組結(jié)合在一起。

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

例如，我們沒(méi)有重命名為org.eclipse.enterprise ，而是從javax重命名為jakarta 。 （只是一個(gè)例子）

因?yàn)槲覀兛梢栽贛icroProfile中進(jìn)行重大更改，所以我們還從MicroProfile API中刪除了品牌，并將API重命名為org.eclipse.enterprise 。

MicroProfile和Jakarta EE關(guān)系。

目前，MicroProfile依賴于Jakarta EE（但并非相反）。 我建議您保持這種關(guān)系，所以只有這種關(guān)系才能實(shí)現(xiàn)。

MicroProfile是進(jìn)行創(chuàng)新和試驗(yàn)的好地方，但不是（必需）向后兼容的地方。 這使MicroProfile在創(chuàng)建新規(guī)范時(shí)可以快速移動(dòng)。

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

由于上述建議的命名方式，因此代碼不會(huì)更改，并且用戶可以繼續(xù)正常運(yùn)行，唯一的不同是Jakarta EE具有新的API，并且該規(guī)范現(xiàn)在由另一個(gè)工作組和另一個(gè)Eclipse進(jìn)程維護(hù)。

配置示例。

如果我們以config為例，則該API在MicroProfile下已經(jīng)成熟，并且（可能）將工作組移至Jakarta。 在Jakarta或JSR下?lián)碛辛硪粋€(gè)標(biāo)準(zhǔn)，可能不是一個(gè)好主意。 如果只有一個(gè)標(biāo)準(zhǔn)，則只有一個(gè)標(biāo)準(zhǔn)。 我認(rèn)為JSR382應(yīng)該退役，轉(zhuǎn)而使用遷移到Jakarta的MicroProfile Config API。

未來(lái)分組。

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

例如，如果我們?cè)趀clipse下創(chuàng)建一個(gè)新的分組，我們將其稱為ClassicProfile，就像MicroProfile一樣，我們可以讓ClassicProfile依賴Jakarta，但不能依賴于Jakarta。 然后，我們可以將不再需要在雅加達(dá)使用的舊API移到此配置文件中。 這意味著使用這些客戶端的客戶仍然可以在不更改代碼的情況下獲得它們，但這意味著我們可以節(jié)食Jakarta EE并使其更薄。

最后的想法

與大多數(shù)架構(gòu)決策一樣，需要權(quán)衡取舍。 在這種情況下，品牌與可移植性。 但是我認(rèn)為這樣做是值得的。 現(xiàn)在這樣做也很重要，我們有機(jī)會(huì)重命名當(dāng)前的javax名稱空間，所以現(xiàn)在還是永遠(yuǎn)不會(huì)。

附錄A

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

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

jakarta ee

總結(jié)

以上是生活随笔為你收集整理的jakarta ee_Jakarta EE的拟议命名空间的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。