102

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 EE 可以做什么而标准 Java 无法做到？

  • 使用标准 Java 可以做什么，而 Java EE 却无法做到？

  • 开发人员何时决定他们“需要”Java EE？

  • 开发人员何时决定他们不需要 Java EE？

  • 为什么 Java EE 库版本与标准 Java 库版本不同步（Java EE 6 与 Java 7）？

谢谢你帮我清除鞭子！

4

5 回答 5

42

为什么库不能在应用服务器环境之外运行？

其实他们可以。大多数库可以直接独立使用（在 Java SE 中）或包含在 .war 中（实际上几乎总是 Tomcat）。Java EE 的某些部分，如 JPA，在其各自的规范中有明确的部分，说明它们应该如何工作和在 Java SE 中使用。

如果有的话，这里所涉及的不是应用服务器环境本身，而是所有其他库的存在以及将它们联合起来的集成代码。

正因为如此，所有类的注释只会被扫描一次，而不是每个库（EJB、JPA 等）都会一遍又一遍地扫描。也正因为如此，CDI 注释可以应用于 EJB bean，并且可以将 JPA 实体管理器注入其中。

为什么我需要像 JBoss 这样庞大的东西来编译简单的代码来发送电子邮件？

这个问题有几个问题：

  1. 对于编译，您只需要 API jar，Web Profile 小于 1MB，完整配置文件则略多于 1MB。
  2. 对于运行，您显然需要一个实现，但“大量”是夸大其词。例如，OpenJDK 大约 75MB，而 TomEE（一个包含邮件支持的 Web Profile 实现）只有 25MB。甚至 GlassFish（一个 Full Profile 实现）也只有 53MB。
  3. Mail 在 Java SE（以及因此 Tomcat）以及使用独立的mail.jar 和 activation.jar时都可以正常工作。

为什么 Java EE 库不是“标准的”并且包含在常规 JVM 下载和/或 SDK 中？

Java EE 在某种程度上是第一次尝试将已经很庞大的 JDK 拆分成更易于管理和下载的块。人们已经在抱怨图形类（AWT、Swing）和小程序在 JRE 中，而他们所做的只是在无头服务器上运行一些命令。然后您还想在标准 JDK 中包含所有 Java EE 库吗？

随着模块化支持的最终发布，我们将拥有一个小型基础 JRE，其中包含许多可作为包单独安装的东西。也许有一天，现在构成 Java EE 的许多甚至所有类也将是这样的包。时间会证明一切。

当标准 Java 真的只有两种主要风格（Oracle JVM/SDK | OpenJDK JVM/JDK）时，为什么会有这么多 Java EE 产品？

Java SE 不仅有两种风格。至少有 IBM JDK、之前的 BEA JDK（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 是最新的。

于 2013-04-03T08:02:08.750 回答
12

以下是对您的问题的一些快速组合的答案...

  • 为什么 JavaEE 库不能在没有应用服务器的情况下运行？ JavaEE 提供的服务（容器管理的事务、容器管理的依赖注入、定时器服务等）固有地涉及符合 JavaEE 的应用服务器（例如：GlassFish、JBoss、WebSphere 等）。因此，如果没有这样的容器，JavaEE 库将毫无用处。“为什么我需要像 JBoss 这样庞大的东西来编译简单的代码来发送电子邮件？ ”你不需要。有很多方法可以在没有 JavaEE 的情况下发送电子邮件……但如果您想以 JavaEE 方式发送电子邮件，您需要一个 JavaEE 容器。

  • 为什么 JavaSE 下载中不包含 JavaEE 库？ 与许多库不包括在内的原因相同：这将是矫枉过正。既然没有应用服务器就无法使用 JavaEE 库，为什么还要包含它们呢？如果开发人员安装应用程序服务器并决定使用 JavaEE，则应下载 JavaEE。

  • 为什么有这么多 JavaEE 产品？ 真的有“这么多”JavaEE 产品吗？如果有，请列出其中的一些。更准确地说，我相信同一个 API有多种实现。

  • 使用 JavaEE 可以做什么，而没有标准 Java 则无法做到？ 很多。如果没有 JavaEE，您就不能依赖应用服务器来管理事务或持久性上下文。您不能允许应用程序服务器在没有 JavaEE 的情况下管理 EJB 依赖项注入。如果没有 JavaEE，您将无法使用应用程序管理的计时器服务。这个问题的答案应该让第一个问题的答案很清楚了…… JavaEE 提供的大部分服务都需要 JavaEE 容器。

  • JavaSE 能做什么而 JavaEE 不能？ 嗯……我不知道。

  • 开发人员何时决定他们需要JavaEE？ 这个问题完全是主观的……但是如果你需要 JavaEE 提供的任何服务，你就开始考虑它。如果您不知道 JavaEE 是什么……您可能不需要它。

  • 开发人员何时决定他们不需要 JavaEE？ 请参阅上一个答案。

  • 为什么 JavaEE 库版本与 JavaSE 版本不同步？ 好问题。我不会假装知道如何回答它......但我猜答案是：“因为它们不同步”。

于 2013-04-02T23:54:06.190 回答
9

从鸟瞰的角度来看，Java EE 是一个平台，即我们可以在其上构建的东西。

从更技术的角度来看，Java 企业版标准定义了一组通常用于构建企业应用程序的 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 EE 可以做什么而标准 Java 无法做到？

由于 Java EE 实现是使用“标准 Java”构建的：没有。但是，如果您要解决典型的企业问题，利用现有库可以节省大量精力，并且使用标准化 API 可以防止供应商锁定。

使用标准 Java 可以做什么，而 Java EE 却无法做到？

没什么，因为 Java EE 包含 Java SE。

开发人员何时决定他们“需要”Java EE？开发人员何时决定他们不需要 Java EE？

一般来说，Java EE API 解决了企业计算中典型的、反复出现的问题。如果你有这样的问题，使用标准解决方案通常是有意义的——但如果你有不同的问题，可能需要不同的解决方案。例如，如果您需要与关系数据库通信，您应该考虑使用 JPA。但是，如果您不需要关系数据库，JPA 不会帮助您。

于 2013-04-03T00:44:16.693 回答
8

什么是 Java EE？

让我们从 wiki 上的规范定义开始：

Java Platform, Enterprise Edition 或 Java EE 是 Oracle 的企业 Java 计算平台。该平台为开发和运行企业软件提供 API 和运行时环境，包括网络和 Web 服务，以及其他大规模、多层、可扩展、可靠和安全的网络应用程序。

这里的要点是 Java EE 是一个提供 API 的平台，而不是一些具体的库。

Java EE 需要什么？

Java EE的主要范围是基于网络的应用程序，不像Java SE面向桌面应用程序开发，具有简单的网络支持。这是它们之间的主要区别。每个应用程序的可扩展性、消息传递、事务处理、数据库支持……随着网络的发展，所有这些方面的需求都在增加。当然，Java SE 提供的很多现成的解决方案对网络开发很有用，所以 Java EE 扩展了 Java SE。

为什么我们需要应用服务器来运行我们的代码？

为什么我们需要操作系统？因为我们需要做很多关于硬件的痛苦工作才能制作最简单的应用程序。如果没有操作系统，您需要一次又一次地这样做。过度简化的操作系统只是一个程序化容器，它为我们提供了一个全局上下文来运行我们的应用程序。

这就是应用服务器。它们允许我们在它们的上下文中运行我们的应用程序，并为我们提供了企业高负载网络应用程序所需的许多高级功能。我们不想编写自己的自行车来解决这个问题，我们想编写能够满足我们业务需求的代码。

这里的另一个例子可能是 Java 的 JVM。

为什么 Java EE 不包含板载应用服务器？

对我来说很难说。我认为，这样做是为了更灵活。Java EE 说他们应该做什么，他们决定如何去做。

为什么 JVM 不包含 Java EE？

因为他们针对不同的市场领域。Java EE 具有许多普通桌面不需要的功能。

为什么有这么多 Java EE 产品？

因为 Java EE 只描述行为。每个人都可以实施。

Java EE 能做什么而 Java SE 不能做？

征服互联网。使用 Java SE 小程序和套接字真的很难做到 :)

Java SE 能做什么而 Java EE 却不能？

如上所述，Java EE 扩展了 Java SE，因此使用 Java EE，您应该能够完成 Java SE 可用的所有操作。

开发人员何时决定他们“需要”Java EE？

当他们需要 Java EE 的强大功能时。上面提到的所有内容。

开发人员何时决定他们不需要 Java EE？

当他们编写通常的控制台或桌面应用程序时。

为什么 Java SE 和 Java EE 的版本不同步？

Java 的技术命名和版本控制总是存在问题。所以这种情况也不例外。

于 2013-04-03T02:02:35.557 回答
6

Java EE 都是关于容器概念的。
容器是一个执行上下文，将在其中运行您的应用程序并提供最后一组服务。每种服务都由名为 JSR 的规范定义。例如 JSR 907、JTA（java transaction Api），它们提供了一种标准方法来管理针对不同资源的分布式事务。
对于给定的 JSR，通常有许多不同的实现，您将使用的实现取决于容器提供者，但您并不介意这一点，因为您确信行为尊重预定义的契约：JSR API。
因此，要利用 Java EE，您需要在容器内运行应用程序。两个主要是 EJB 和 servlet 容器，它们都存在于任何 Java EE 认证的应用程序服务器上。

所有这些的目的是定义一个标准的执行环境，以允许仅使用必需品 id.est 打包您的应用程序。你的事。它避免了依赖一组未知的和不同的第三方库，否则您必须打包并提供给您的应用程序，并且这些库可能与服务器上的其他应用程序发生冲突。在 Java EE 中，您知道所有标准的非功能性需求，如安全性、事务、可伸缩性、远程调用等等，都将由容器提供（针对在其中运行的所有应用程序进行分解），您只需将工作基于它。

于 2013-04-03T07:37:48.727 回答