我們都聽說過它的到來。 昨天，JavaEE和GlassFish的官方路線圖更新已發(fā)布 。 從標(biāo)題開始，整個(gè)帖子基本上都是關(guān)于一件事的：今天我們知道的GlassFish Server已從完整的產(chǎn)品轉(zhuǎn)為玩具產(chǎn)品。

從Sun到Oracle的漫長道路

從一開始，GlassFish就值得擔(dān)心。 合并后，花了一些時(shí)間使堅(jiān)持“甲骨文殺死GlassFish”的聲音保持沉默。 甲骨文在培養(yǎng)社區(qū)并將他們的東西保持在一起方面做得不錯(cuò)。 我自己寫了兩個(gè)博客，以幫助大家了解。 為期100天的發(fā)行版2.1.2和3.0.1已成為證明改進(jìn)意愿的里程碑。 一段時(shí)間后，我們都對(duì)此感到滿意。 甚至早在2013年1月，我就整理了一份開源應(yīng)用服務(wù)器列表，并選擇了其中一個(gè)。 最終標(biāo)準(zhǔn)是供應(yīng)商支持。 這將WAS CE踢出了游戲。 從昨天開始，它還將刪除GlassFish。 剩下的兩個(gè)替代方案變成了一個(gè)：JBoss AS7 / WildFly。

客戶需要對(duì)其服務(wù)器的支持

但是，來吧，這是什么問題？ 誰想要支持？ 甲骨文顯然沒有從商業(yè)許可證中賺到足夠的錢，否則他們根本不會(huì)殺死該產(chǎn)品。 這可能不是很明顯的原因，但我可以提供某種解釋。 首先，如果供應(yīng)商不僅在開發(fā)開源替代方案，而且還提供商業(yè)產(chǎn)品，那么將導(dǎo)致不同的事情，這些事情將被隱式地處理：

• 客戶發(fā)現(xiàn)的變更/錯(cuò)誤進(jìn)入oss版本
• 變化需要具有體面的品質(zhì)。 知道需要支持其解決方案的開發(fā)人員將（至少在一點(diǎn)點(diǎn)上）更加謹(jǐn)慎地實(shí)施工作。
• 知道自己的東西在適當(dāng)?shù)呢?fù)載下運(yùn)行的開發(fā)人員會(huì)不同地實(shí)現(xiàn)它。 非功能性標(biāo)準(zhǔn)的完整列表隨此移動(dòng)而變化。
• 客戶需要更頻繁的發(fā)行版和安全補(bǔ)丁，這些發(fā)行版和安全補(bǔ)丁也最終出現(xiàn)在oss版本中。
• 與使用免費(fèi)和開源服務(wù)器的客戶相比，客戶有不同的要求。 一個(gè)突出的例子是集群。 在OSS項(xiàng)目中很少使用。

另一個(gè)因素是經(jīng)驗(yàn)。 我絕不會(huì)嘗試在與生產(chǎn)環(huán)境完全不同的環(huán)境下開發(fā)項(xiàng)目。 即使WLS和GF都至少了解彼此的部署描述符，這里也存在著很高的風(fēng)險(xiǎn)，即這種設(shè)置是通往麻煩的道路。

我的論點(diǎn)基本上是，通過更改產(chǎn)品的一些相關(guān)非功能要求，提供商業(yè)分銷的需求可以提高整體質(zhì)量和可靠性。 如果不在那里，那么沒人會(huì)照顧他們……他們將不會(huì)在那里。

為什么Java EE會(huì)死于GlassFish？

Java EE TCK的質(zhì)量受到了很多質(zhì)疑。 過去，許多人將GF用作不工作代碼的展示。 最重要的是，某些生產(chǎn)場景和錯(cuò)誤會(huì)導(dǎo)致不同的實(shí)現(xiàn)方式，最后但并非最不重要的是規(guī)格。 所有實(shí)際的現(xiàn)場知識(shí)都掌握在團(tuán)隊(duì)中。 我不知道Oracle在內(nèi)部如何運(yùn)行WLS開發(fā)，但我希望它與團(tuán)隊(duì)為GF做的工作有所不同，可能會(huì)更重。 從基于WLS的客戶案例中提取規(guī)范邊緣案例并刪除產(chǎn)品特定零件肯定會(huì)比較棘手，而且不會(huì)經(jīng)常發(fā)生。 因此，我希望規(guī)范在某種程度上不會(huì)受到Oracle驅(qū)動(dòng)，而通常不會(huì)那么成熟。 這不是故事中最糟糕的部分。 但是考慮到在這一領(lǐng)域有一些非常聰明的人正在工作，我希望他們的激情和知識(shí)會(huì)被很多人遺漏。 而且沒有人在那里趕上他們的下落。

GlassFish的哪一部分會(huì)死？

因此，GlassFish將保留即將發(fā)布的Java EE標(biāo)準(zhǔn)的參考實(shí)現(xiàn)。 出于這一原因，Oracle需要它在周圍。 隨著新興的JCP越來越開放，他們不僅僅將WLS定義為RI也就不足為奇了。 但這將是將要死亡的事物和即將發(fā)生的事物之間的切入點(diǎn)。 我在這里沒有任何見解，我只是在推測，我可以對(duì)這個(gè)博客上的第一條評(píng)論做出有根據(jù)的猜測，但是對(duì)我來說，最重要的是，Java EE規(guī)范未涵蓋的所有內(nèi)容都是很快就會(huì)老化。 這可能包括群集，并且可以肯定的是，某些管理功能和安全性也是不錯(cuò)的選擇（PAM領(lǐng)域和其他）。 坦率地說，我無法確認(rèn)其中任何一個(gè)。 純粹是猜測！

這有什么好處嗎？

好吧，是的：此舉為加強(qiáng)競爭留下了廣闊的空間。 這不僅是WildFly，而且肯定是TomEE和tomitribe。 恭喜他們。 進(jìn)一步，許多客戶將節(jié)省大量許可費(fèi)用。 GF和WLS的許可不同，使用WLS標(biāo)準(zhǔn)為客戶提供了選擇正確許可的更多選擇。 至少WLS團(tuán)隊(duì)將得到加強(qiáng)，而那些不必在不同產(chǎn)品上頻繁工作的人不再需要改頭換面。

甲骨文可以做些什么使之值得嗎？

到今天為止，這已經(jīng)是毫無意義的死亡。 用戶可以簡單地坐下來等待下一個(gè)次要版本的發(fā)布，該次發(fā)布可能每年一次。 如果您一直抱怨直到今天發(fā)布的頻率不高，請(qǐng)準(zhǔn)備以后再做。 實(shí)際上，甲骨文可以采取以下幾項(xiàng)措施來使每個(gè)人（不僅限于他們自己）成為戰(zhàn)略行動(dòng)：

開發(fā)并支持明確的升級(jí)路徑。 找到一種方法至少支持基于非常輕量級(jí)服務(wù)器的開發(fā)設(shè)置，并且僅在生產(chǎn)中部署到完全成熟的WLS。 鑒于給定的功能和兩者之間的差異，到目前為止，這幾乎不是一個(gè)可行的故事。

為GF用戶提供有吸引力的許可產(chǎn)品。 不僅對(duì)于今天的客戶而言，對(duì)所有人而言。 甚至更好：在OTN許可證中提出一系列許可條款，使NPO可以免費(fèi)使用WLS。

因此，開源GF（獲得了體面的許可）并吸引了社區(qū)的貢獻(xiàn)。 到目前為止，使用的基礎(chǔ)架構(gòu)和OCA使得這一切成為不可能。 將服務(wù)器代碼（包括模塊）移至GitHub并任命一名變更經(jīng)理，負(fù)責(zé)審查并提取建議的修訂和變更。 讓社區(qū)決定發(fā)布。

回聲在大廳里消失了

基本上，這個(gè)消息并不令人驚訝。 我們都知道這一舉動(dòng)。 有兩個(gè)服務(wù)器而不是一個(gè)是雙重負(fù)擔(dān)。 通過BEA合并，甲骨文殺死了自己的應(yīng)用服務(wù)器。 現(xiàn)在輪到GlassFish了。 Oracle已經(jīng)嘗試通過合并團(tuán)隊(duì)來減少維護(hù)它所需的精力，并且還討論了將WLS合并到HK2或擴(kuò)展兩臺(tái)服務(wù)器使用相同組件的不同選擇。 發(fā)生了一些事情，將昨天宣布的時(shí)間推遲了幾個(gè)月，但最終沒有阻止它。 所以。 RIP GlassFish。 很不錯(cuò)。 感謝所有的魚。

參考： RIP GlassFish –感謝所有的魚。 來自我們的JCG合作伙伴 Markus Eisele在Java的企業(yè)軟件開發(fā)博客中。

翻譯自: https://www.javacodegeeks.com/2013/11/r-i-p-glassfish-thanks-for-all-the-fish.html

總結(jié)

以上是生活随笔為你收集整理的RIP GlassFish –感谢所有的鱼。的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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