Java EE为年轻的Java开发人员提供了这个“神秘的裹尸布” - 我一直试图提升自己很长一段时间但收效甚微。
混淆起因于：
Java EE似乎既是一个库又是一个平台 - 有多种方法可以“获取”Java EE库，通常来自Oracle的Java EE SDK下载。但是，除非您的代码正在运行或者可以访问Java EE应用程序服务器（例如JBoss，GlassFish，Tomcat等），否则Java EE库将无法工作或编译。为什么？库不能在应用程序服务器环境之外运行吗？为什么我需要像JBoss那样大量编写简单代码才能发送电子邮件？
为什么Java EE库不是“标准”并包含在常规JVM下载和/或SDK中？
为什么只有两种主要标准Java（Oracle JVM / SDK | OpenJDK JVM / JDK）才有这么多Java EE产品？
使用标准Java无法对Java EE做些什么？
使用标准Java可以用Java EE做些什么呢？
开发人员何时决定“需要”Java EE？
开发人员何时决定不需要Java EE？
为什么Java EE库版本与标准Java库版本（Java EE 6与Java 7）不同步？
感谢您帮我清除鞭子！
答案 0 :(得分：38)
为什么库不能在应用服务器环境之外运行？
实际上他们可以。大多数库可以直接单独使用（在Java SE中）或包含在.war中（实际上几乎总是Tomcat）。 Java EE的某些部分（如JPA）在各自的规范中都有明确的部分，说明它们应该如何工作并在Java SE中使用。
如果有的话，这不是一个应用服务器环境本身，而是存在所有其他库和集成它们的集成代码。
正因为如此，对于所有类而不是每个库（EJB，JPA等）一遍又一遍地进行扫描，只会扫描一次注释。也正因为如此，CDI注释可以应用于EJB bean，JPA实体管理器可以注入它们。
为什么我需要像JBoss那样大量编写简单代码才能发送电子邮件？
这个问题存在一些问题：
为什么Java EE库不是“标准”并包含在常规JVM下载和/或SDK中？
Java EE在某种程度上是首次尝试将已经很大的JDK拆分成更易于管理和下载的块。人们已经在抱怨图形类（AWT，Swing）和Applet都在JRE中，而他们所做的就是在无头服务器上运行一些命令。那么您还想在标准JDK中包含所有Java EE库吗？
随着模块化支持的最终发布，我们将只有一个小的基础JRE，其中许多东西可以单独安装为软件包。也许有一天，现在构成Java EE的很多甚至所有类都将成为这样的包。时间会证明。
当标准Java（Oracle JVM / SDK | OpenJDK JVM / JDK）只有两种主要版本时，为什么会有这么多Java EE产品？
Java SE不仅仅有两种风格。至少有IBM JDK，以前的BEA（JRocket，由于收购而被合并到Oracle / Sun中），各种其他开源实现以及一系列嵌入式使用实现。
Java SE和EE背后的原因是许多供应商和组织可以实施它，因此它鼓励竞争并降低供应商锁定的风险。
与C和C ++编译器完全没有什么不同，在这些编译器中，您有许多竞争产品，并且都符合C ++标准。
为什么Java EE库版本与标准Java库版本不同步（Java EE 6与Java 7）
Java EE建立在Java SE之上，因此它落后了。版本确实对应。 Java EE 5需要Java SE 5. Java EE 6需要Java SE 6等。只是当Java SE X是最新的时，Java EE X-1才是最新的。
答案 1 :(得分：12)
以下是一些快速撰写的问题答案......
为什么JavaEE库在没有应用服务器的情况下无法运行？ JavaEE提供的服务（容器管理事务，容器管理依赖注入，计时器服务等）本质上涉及JavaEE兼容的应用程序服务器（例如：GlassFish，JBoss，WebSphere等......）。因此，没有这样的容器，JavaEE库就没有用处。 “为什么我需要像JBoss一样庞大的东西才能编译简单的代码来发送电子邮件？”你没有。有一些方法可以在没有JavaEE的情况下发送电子邮件......但是如果你想以JavaEE的方式进行，你需要一个JavaEE容器。
为什么JavaEE库不包含在JavaSE下载中？ 与许多图书馆不包括在一起的原因相同：它会有点过分。由于在没有应用程序服务器的情况下甚至无法使用JavaEE库，为什么还要包含它们呢？如果开发人员安装应用程序服务器并决定使用JavaEE，则应下载JavaEE。
为什么有这么多JavaEE产品？ 是否真的有“这么多”JavaEE产品？如果是，请列出其中一些。更准确地说，我相信相同API的多个实现 。
如果没有标准Java，他们怎能处理JavaEE？ 许多。如果没有JavaEE，您不能依赖应用程序服务器来管理事务或持久性上下文。如果没有JavaEE，您不能允许应用程序服务器管理EJB依赖项注入。没有JavaEE，您无法使用应用程序管理的计时器服务。这个问题的答案应该使第一个问题的答案非常清楚...... JavaEE提供的大多数服务都需要一个JavaEE容器。
对于JavaSE，您无法用JavaEE做什么？ 嗯......我不知道。
开发人员何时决定需要 JavaEE？ 这个问题是完全主观的......但如果您需要JavaEE提供的任何服务，您就会开始考虑它。如果您不知道JavaEE是什么......您可能不需要它。
开发人员何时决定他们不需要JavaEE？ 见上一个答案。
为什么JavaEE库版本与JavaSE版本不同步？ 好问题。我不会假装知道怎么回答......但我猜的答案是：“因为他们没有同步”。
答案 2 :(得分：8)
从鸟瞰角度来看，Java EE是一个平台，也就是我们可以构建的东西。
从技术角度来看，Java Enterprise Edition标准定义了一组通常用于构建企业应用程序的API。这些API由应用程序服务器实现 - 是的，不同的应用程序服务器可以自由使用Java EE API的不同实现。
但是，除非您的代码正在运行或可以访问Java EE应用程序服务器（例如JBoss，GlassFish，Tomcat等），否则java ee库将无法运行或编译。
您针对Java EE API进行编译，因此您只需在编译时使用这些API。在运行时，您还需要实现这些API，即应用程序服务器。
为什么我需要像JBoss那样大量编写简单代码才能发送电子邮件？
你没有。但是，如果您希望使用Java EE API发送邮件，则需要在运行时实现该API。这可以由应用程序服务器提供，也可以由添加到类路径的独立库提供。
为什么Java EE库不是“标准”并包含在常规JVM下载和/或SDK中？
因为只有API是标准化的，而不是实现。
为什么有这么多Java EE产品
因为人们不同意实施某些功能的正确方法。因为不同的供应商争夺市场份额。
使用标准Java无法对Java EE做什么？
由于Java EE实现是使用“标准Java”构建的：没有。但是，如果要解决典型的企业问题，利用现有库可以节省大量工作，并且使用标准化API可以防止供应商锁定。
使用Java EE无法对标准Java做什么？
没有，因为Java EE包含Java SE。
开发人员何时决定“需要”Java EE？开发人员何时决定他们不需要Java EE？
一般来说，Java EE API解决了企业计算中典型的，反复出现的问题。如果您遇到这些问题，使用标准解决方案通常是有意义的 - 但如果您遇到不同的问题，可能需要采用不同的解决方案。例如，如果您需要与关系数据库通信，则应考虑使用JPA。但是，如果您不需要关系数据库，JPA将无法帮助您。
答案 3 :(得分：8)
让我们从维基的正规性定义开始：
Java平台，企业版或Java EE是Oracle的企业 Java计算平台。该平台提供API和运行时 开发和运行企业软件的环境，包括 网络和网络服务，以及其他大规模，多层次的， 可扩展，可靠和安全的网络应用程序。
这里的要点是Java EE是一个提供API的平台，而不是一些具体的库。
Java EE的主要范围是基于网络的应用程序，不同于面向桌面应用程序开发的Java SE，具有简单的网络支持。这是他们之间的主要差异。 可扩展性，消息传递，事务处理，对每个应用程序的数据库支持......随着网络的发展，所有这些的需求都在增加。 当然，Java SE提供的许多现成解决方案对网络开发很有用，因此Java EE扩展了Java SE。
为什么我们需要操作系统？因为硬件需要做很多艰苦的工作才能实现最简单的应用。没有操作系统，你需要一次又一次地做。过度简化的操作系统只是一个程序化容器，它为我们提供了运行应用程序的全局上下文。
这就是应用程序服务器。它们允许我们在其上下文中运行我们的应用程序，并为我们提供了许多企业高负载网络应用程序所需的高级功能。而且我们不想编写自己的自行车来解决这个问题，我们希望编写能够满足我们业务需求的代码。
这里的另一个例子可能是JVM for Java。
很难说对我来说。我认为，这是为了获得更大的灵活性。 Java EE说他们应该做什么，他们决定如何做。
因为他们针对不同的市场领域。 Java EE具有许多通常桌面不需要的功能。
因为Java EE仅描述了该行为。每个人都可以实现它。
征服互联网。使用Java SE applet和套接字真的很难：）
如上所述，Java EE扩展了Java SE，因此使用Java EE，您应该能够完成Java SE可用的所有操作。
当他们需要Java EE的强大功能时。所有上面提到的。
当他们编写通常的控制台或桌面应用程序时。
Java总是在技术命名和版本控制方面遇到麻烦。所以这种情况也不例外。
答案 4 :(得分：6)
Java EE就是容器概念。
Container是一个执行上下文，在其中运行您的应用程序，并提供最后一组服务。每种服务都由名为JSR的规范定义。例如JSR 907，JTA（java事务Api），它提供了一种管理针对不同资源的分布式事务的标准方法。
对于给定的JSR，通常有许多不同的实现，您将使用的实现取决于容器提供者，但是你并不介意这一点，因为你确定行为符合预定义的合同：JSR API。
因此，为了利用Java EE，你需要在容器内运行你的应用程序。两个主要的是EJB和servlet容器，它们都存在于任何Java EE认证的应用程序服务器上。
所有这一切的目的是定义一个标准的执行环境，允许仅使用必需品id.est打包您的应用程序。你的事。它可以避免依赖于您必须打包并提供给您的应用程序的未知和各种第三方库，这些库可能是与服务器上其他应用程序冲突的根源。在Java EE中，您知道所有标准的非功能性需求（如安全性，事务，可伸缩性，远程调用等）都将由容器提供（对其中运行的所有应用程序进行分解），您只需将工作建立在其上。