随着Java EE 6的发布，我看到了很多反对升级到新平台的反复出现的、但相当奇怪的论点。这些人通常使用一个由Tomcat或Jetty这样的Servlet引擎和Hibernate、Spring等一些开源框架组成的“自建”堆栈。
当然，我确信有很多很好的理由选择非标准的开源技术作为EE平台中包含技术的替代品或补充品。高兴的是，在EE 6中，您可以使用任何您喜欢的开源框架 - 事实上，Servlet 3和CDI包含了一系列功能，以使第三方框架的集成尽可能无缝。因此，这并不是不使用EE 6的理由。
相反，我看到人们提出了以下观点
升级EE应用服务器是“困难的”
这看起来更像是一个组织特定的政治问题，而不是应用服务器本身的技术问题。当然，升级GlassFish或JBoss这样的服务器通常是一个非常简单的任务。（升级第三方框架也绝对不是总是一帆风顺的。）显然，一些组织已经实施了一系列非常沉重的服务器升级流程，而没有为在服务器“内部”运行的框架引入类似流程，这使得开发团队部署升级到第三方框架比升级到应用服务器本身更容易。
在我看来，这更像是一个发展更响应性流程的论点，而不是放弃Java EE的论点。运行旧或有缺陷的服务器平台的风险确实存在，而且您的流程不应该鼓励这种做法。
但从实际的角度来看，几乎所有人在不久的将来都会想要升级到Servlet 3。这意味着服务器升级，无论您使用Tomcat、Jetty、JBoss、GlassFish、Resin、WebLogic、Oracle还是WebSphere。这是一个同时迁移到EE 6 Web配置文件的绝佳机会。事实上，这是一个黄金机会。
EE应用服务器是“臃肿的”
反对意见是EE服务器包含团队目前（目前）未使用的功能。好吧，那就不要用！哦。
这个论点通常演变成对jar文件大小的讨论，以及servlet引擎和第三方框架占用的磁盘空间与EE应用程序服务器部署的比较。一开始，这个论点就有几个问题
- 在美元衡量下，我们谈论的磁盘空间只是微不足道的，
- 应用war文件的大小实际上比服务器安装的大小更重要，在服务器中包含更多功能有助于减小war文件的大小。
但拒绝这个论点的最大理由是新Java EE 6网络配置显然是如此不臃肿。当第一个认证的网络配置服务器进入市场，我们将有一个新的“恰到好处”的甜点位置，介于“太大”的完整EE应用服务器和“太小”的servlet容器之间。
J2EE和EJB2很糟糕！
这里的想法是我们可以通过拒绝使用通过JCP标准化过程的一切来报复给我们实体bean的人。当然，这是一种特别的报复形式，用户割自己的鼻子。哦，还有
- 那是在八年前！这真的是你的最佳选择吗？
- 从JCP产生了几个优秀的规范，其中一些你几乎肯定正在使用。不，JCP的成功率并没有达到100%——远非如此——但是，那么，谁有呢？
- 在EE 6上工作的大多数人像你一样讨厌EJB2和J2EE（或者更多）。这就是他们加入JCP的原因——帮助解决问题。例如，这篇博客文章的作者就是Hibernate的创造者。你真的在尝试给他关于EJB2问题的讲座吗？
- 发明实体bean的人可能都已经退休了！
事实是，Java EE 6网络配置中的技术从“非常充分”到“酷极了”都有。你不尝试自己使用，既没有给你自己也没有给你的雇主带来任何好处。
应用程序服务器可移植性是神话！
真的吗？那么为什么我们看到这么多人在不同应用程序服务器之间迁移应用程序？哦，我明白了，你是指100%完美的世界，零更改到我的应用程序的理想可移植性。好吧，我理解，nerd心态对绝对真理和柏拉图思想有弱点，但在这个问题上，请退一步，好吗？
从可移植性的角度来看，哪种场景对你来说更有利
- 99%的代码和85%的外部元数据在服务器平台之间兼容——其余的1%和15%可以相对容易地移植
- 40%的代码和80%的外部元数据绑定到一个非标准、单一供应商的容器架构
当我说这个观点时，通常会导致立即的主题转变，从“应用程序服务器可移植性是神话”到“我不关心容器可移植性”。好吧，这是你的价值判断，你有权这样做。但是，你的主题转变承认了应用程序服务器可移植性是真实存在的。并且这对许多组织是有用的。
更新：我仍在等待看到来自替代技术倡导者的更多实质性的对EE 6的批评。我认为上述论点不是实质性的，因为在意义上，它们没有提出关于EE平台用于应用程序开发的可使用性的真实技术问题。最新一轮规范的质量似乎使反EE阵营（暂时？）缺少弹药。
