RIP GlassFish –感谢所有的鱼。

我们都听说过它的到来。昨天，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