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

從Sun到Oracle的漫長道路

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

客戶需要對其服務器的支持

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

• 客戶發現的變更/錯誤進入oss版本
• 變化需要具有體面的品質。 知道需要支持其解決方案的開發人員將（至少在一點點上）更加謹慎地實施工作。
• 知道自己的東西在適當的負載下運行的開發人員會不同地實現它。 非功能性標準的完整列表隨此移動而變化。
• 客戶需要更頻繁的發行版和安全補丁，這些發行版和安全補丁也最終出現在oss版本中。
• 與使用免費和開源服務器的客戶相比，客戶有不同的要求。 一個突出的例子是集群。 在OSS項目中很少使用。

另一個因素是經驗。 我絕不會嘗試在與生產環境完全不同的環境下開發項目。 即使WLS和GF都至少了解彼此的部署描述符，這里也存在著很高的風險，即這種設置是通往麻煩的道路。

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

為什么Java EE會死于GlassFish？

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

GlassFish的哪一部分會死？

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

這有什么好處嗎？

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

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

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

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

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

因此，開源GF（獲得了體面的許可）并吸引了社區的貢獻。 到目前為止，使用的基礎架構和OCA使得這一切成為不可能。 將服務器代碼（包括模塊）移至GitHub并任命一名變更經理，負責審查并提取建議的修訂和變更。 讓社區決定發布。

回聲在大廳里消失了

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

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

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

總結

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

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