Java Enterprise Edition是全球Java社区中最大的困惑来源之一。 就像《星球大战》和《星际迷航 》之间的区别一样，对于“原力觉醒”是他们在这部电影中看过的第一部电影的人来说。

奇怪的是，即使您有使用EE进行开发的经验，但整个情况通常仍然很模糊。 在本文中，我们将收集所有最新消息，并在Java EE 8专家组的Werner Keil和前Oracle Java EE推广者和创始人Reza Rahman的帮助下，仔细研究Java EE以消除迷雾Java EE守护者。

新帖：Java EE与Java SE：Oracle是否放弃了企业软件？ https://t.co/3wZHYgogKn pic.twitter.com/XXDez1OkRr

— Takipi（@takipid） 2016年4月21日

Java EE与Java SE究竟有何不同？

首先，我们需要做出重要的区分。 Java EE构建在Java SE之上。 与Java SE不同，Java企业版正式“只是”一个规范，Oracle以及RedHat和IBM等其他供应商提供了实际的实现（例如Glassfish参考实现）。

SE的API提供了Java语言（java。*软件包）的标准核心功能，而EE的API（javax。*）提供了Java的扩展，这些扩展对于开发大型应用程序非常有用。 话虽如此，可能会有导致额外混乱的例外。 例如，Swing最初是作为扩展，而最终成为核心Java的一部分。 这不是防弹概念。

我们与Java EE 8专家组成员Werner Keil联系以获得进一步的见解。 Werner说：“最大的误解是API是否是规范的编码形式，还是其实现”。 “现在几乎每个Java EE项目都将其视为实现，因此，绝大多数Java代码的所有代码都受到越来越开放的许可证的保护。 除了技术兼容性套件（TCK）测试套件外，专有的封闭式TCK仍然存在很大的问题，只有Oracle和公司许可方才能使用。

附带说明，这些许可问题最终导致Apache软件基金会在2010年从Java Community Process执行委员会撤回其成员资格 。

那么，EE规范实际上包括什么？

实际上，Java EE是企业Java扩展的总体规范。 它的核心包括独立的功能，例如企业Java Bean（EJB），Java Servlet，Rest API（JAX-RS），上下文和依赖注入（CDI）等。

每个新版本都包括对单个技术的升级以及新功能。 例如，Java EE 8有望包括具有HTTP 2.0支持的Servlet 4.0规范。

由于Java是向后兼容的，因此您还可以在新的SE版本之上运行较旧的EE版本，并享受新的语言功能。 例如，在Java SE 8之上针对lambda和流的Java EE 7兼容实现，因此您无需等待Java EE 8即可使用它。

Servlet规范是Java EE的主要功能。 当前版本为v3.1，正在开发v4.0。 它最受欢迎的实现之一来自TomEE ，它是Tomcat的EE兼容版本。

重量级Java EE是一个神话

与流行的看法相反，Java EE 比看起来轻得多 。 工件大小，构建时间和部署时间等属性可能很小。 轻量级是设计决策，其他被认为是轻量级的框架可能会成为……重量级。

“关于Java EE的最常见的误解可能是它太大，太重或整体，并且不如Play！，Spring，Node.js或所有其他“ hip”以及新的或更旧的替代品那么灵活。 我们在Raspberry Pi上运行了整个Tomcat或Glassfish服务器” – Werner Keil

在生产中调试Java EE

分布式生产环境（尤其是微服务架构）经常遇到的问题是了解生产中发生的情况。 虽然不是特定于EE，但是始于一项服务的问题可能会在其他地方引起麻烦，然后您就独自探索日志，试图寻找甚至可能不存在的线索。

在塔基皮（Takipi），我们正在采用一种新的方法来解决此类问题。 每当发生异常，日志错误或警告时，我们都会提供所有必要的数据以找出其根本原因。 这包括错误栈跟踪中的所有相关源代码和状态，请参见此处 。

Takipi的错误分析视图：源，堆栈和状态

Java EE与Java SE的发布周期

Java EE的工作在一个单一的Java规范请求（ 这里是Java EE 8的请求）下进行管理，并等待SE完成以定义确切的规范。 下表总结了所有版本的发布日期：

为什么在SE之后发布EE通常需要2年？

“我认为这在历史上是随着时间而演变的。 Werner Keil说，在Java于1995年正式启动两年多一点之后，1998年就出现了EJB之类的J2EE技术​​。 “一旦越来越多的公司和贡献者开始在JCP下帮助Java EE，企业技术自然会花一些时间来准备，测试和集成EE框架下的所有组件。”

Werner补充说：“我个人认为，即使对于大型公司用户，将Java EE版本X严格绑定到同一JDK版本X的需求也变得不那么重要。 默认情况下，已有多家供应商开始将其最新的Java EE 6或7兼容产品与Java SE 8捆绑在一起。”

“一旦Java EE 8准备就绪，我们有望看到Java SE 9及其Jigsaw模块化系统不仅最终，而且相对成熟。 企业服务器可能需要花费一些时间来应对这一巨大的步骤，但是一旦正确理解并采用了模块化，我发现EE可能比SE带来更大的收益。 相当数量的EE配置文件应该会增长，并利用基础平台可以提供的所有可选项和模块化。”

Java EE 8的当前状态是什么？

Java EE 8预计将于2017年上半年发布。看来我们预计还会遇到更多延迟。 Werner Keil详细阐述了这些问题：

“不幸的是，不仅是由于Java SE 9的延迟，而且Oracle内部资源的大量转移似乎是为了为其（私有）云客户提供服务，相反，几乎所有针对Java EE 8的Oracle领导的JSR都被延迟了。 ”

“即使Oracle担任联合规范主管的JCache似乎也没有真正的形状，只是将Java EE 8的企业功能的关键方面（例如事务）简单地丢进了Java EE 8中。”

“这些缺失的零件都由专有的供应商专有扩展涵盖，无论是Oracle（Coherence），Hazelcast还是其他供应商。 也许这实际上将是最终的结果。 “

“ Java EE社区中许多人普遍担心的是，Java EE和相关标准已变成了一个“无花果”，可以涵盖专有的，大多是封闭源代码的产品或服务，这些产品或服务在“云”中运行，而您只需租用并付费即可。对于。”

由于优先级看似不断变化，Oracle Java EE传播者Reza Rahman与Oracle分道扬and，创立了一个社区驱动的计划，即Java EE Guardians。 “公正地看待它，无非是Java EE的“采用JSR”。 尽管很少有人尝试让JUG或其成员通过Adopt-a-JSR程序采用Java EE JSR，但实际上，它仅限于Java SE或独立JSR，Oracle几乎所有活动和涉及的主要JUG都完全专注于采用OpenJDK。 在过去，企业部门一直被一些大型供应商（例如IBM，BEA / Oracle或JBoss）视为一件事情。 “

“让像TomiTribe或Payara这样的小公司在开源方面做出贡献，就像说JBoss甚至IBM押注大量由开源驱动的技术（如OpenStack或WebSphere Liberty Profile）一样，这意味着范式发生了巨大的变化，至少许多甲骨文的公司和法律人士都愿意这样做似乎还没有完全理解。”

Java EE Guardians

为了进一步了解新社区，我们已与Reza Rahman联系以获取更多详细信息。

“我们是一群热爱Java EE的人，他们非常关注Oracle对开放标准的承诺。 我们致力于尽一切努力使Java EE社区向前发展” – Reza Rahman

Reza继续说道：“ Oracle和Sun一直对Java EE的发展产生不健康的影响。 Oracle当前的不活动状态使这种现实的弊端更加明显。 从长远来看，我认为社区和其他供应商（如RedHat，IBM，Tomitribe和Payara）将更加积极地推动Java EE的正确答案。”

“ Java EE的当前状态令人担忧。 生态系统不断增强，并且比以往任何时候都充满活力，背后有许多热情的人。 尽管如此，Oracle主导的JSR上Oracle资源的活动却显着放缓。 除非Oracle的明显行为发生变化，社区大大提高了贡献或其他供应商弥补了因Oracle不活动而造成的进度差距，否则要满足当前的Java EE 8时间表将非常困难。

Java的父亲James Gosling博士与Java EE Guardians站在一起。 即将有更多详细信息。 // @javaee_guardian pic.twitter.com/MqqT6VAXJQ

— Reza Rahman（@reza_rahman） 2016年4月11日

“ Java EE的发布时间是一个复杂的问题。 现实情况是，Java EE比Java SE或Spring做得多。 实际上，Spring直接受益于Java EE中完成的工作。”

“我相信，如果社区和其他供应商进一步参与进来，工作实际上会更快地进行。” – Reza Rahman

Java EE替代品

纵观更广泛的生态系统，我们看到其他解决方案以不同的向量更快地发展。 例如，Servlet容器Jetty不需要等待Se​​rvlet 4.0规范完成就已经支持HTTP 2.0。 总体而言，Spring从以前的规范中受益，可以与Java EE竞争。

最后的想法

再次感谢Werner Keil和Reza Rahman与我们分享了他们对这篇文章的见解！ 我们很高兴看到您的评论，并了解您在Java EE方面的个人经验。

Werner Keil是一家领先的汽车供应商的DevOps Build Manager，曾在一家大型瑞士保险公司等公司工作过。 除了在大型公司工作外，他还经营着自己的创意人才公司Creative Arts＆Technologies，并在业余时间管理和支持开源项目以及Java Community Process执行委员会的个人成员。

Reza Rahman是Java EE Guardians核心的一部分，并且在Oracle内外都参与Java EE很长时间了。 他是CapTech Consulting的长期顾问，并且是Oracle的官方Java技术专家。 经常发表演讲的人，作家以及JavaOne RockStar演讲者奖的获得者。 多年来，他还是Java EE，EJB和JMS专家组的成员。

翻译自: https://www.javacodegeeks.com/2016/04/java-ee-vs-java-se-oracle-given-enterprise-software.html