Java EE到底是什么？[关闭]

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）不同步？

感谢您帮助我清除log！

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

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

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

因此，注释将只对您所有的类扫描一次，而不是对每个库（EJB，JPA等）进行一次又一次的扫描。也正因为如此，CDI批注可以应用于EJB bean，并且JPA实体管理器可以注入到它们中。

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

这个问题有些错误：

1. 对于编译，您只需要API jar，Web个人资料的大小低于1MB，完整个人资料的大小则超过1MB。
2. 为了运行，您显然需要一个实现，但是“大量”夸大了事情。例如，OpenJDK约为75MB，而TomEE（包含邮件支持的Web Profile实现）仅为25MB。甚至GlassFish（完整配置文件的实现）也只有53MB。
3. 使用独立的mail.jar和activation.jar，从Java SE（因此也从Tomcat）在Mail上运行良好。

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

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

随着模块化支持的最终发布，我们将只有一个小型的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和C ++编译器中，您有许多竞争产品，而且都遵循C ++标准。

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

Java EE建立在Java SE之上，因此落后于Java。版本确实对应。Java EE 5需要Java SE5。JavaEE 6需要Java SE 6，依此类推。多数情况下，只有Java SE X是最新的，而Java EE X-1是最新的。

以下是一些快速解答您问题的答案...

• 如果没有应用程序服务器，为什么JavaEE库无法运行？ JavaEE提供的服务（容器管理的事务，容器管理的依赖项注入，计时器服务等）固有地涉及JavaEE兼容的应用服务器（例如：GlassFish，JBoss，WebSphere等）。因此，如果没有这样的容器，JavaEE库将毫无用处。“ 为什么我需要像JBoss这样庞大的功能来编译简单的代码来发送电子邮件？ ”您不需要。有一些不使用JavaEE来发送电子邮件的方法...但是，如果要使用JavaEE方式进行发送，则需要JavaEE容器。

• 为什么JavaSE下载中不包含JavaEE库？ 没有包含许多库的原因相同：这太过分了。既然没有应用程序服务器，您甚至无法使用JavaEE库，那么为什么还要包括它们呢？如果开发人员安装应用程序服务器并决定使用JavaEE，则应下载JavaEE。

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

• 没有标准Java就无法使用JavaEE做什么？ 很多。没有JavaEE，您不能依靠应用程序服务器来管理事务或持久性上下文。没有JavaEE，您将不允许应用程序服务器管理EJB依赖项注入。没有JavaEE，您将无法使用应用程序托管的计时器服务。这个问题的答案应该使第一个问题的答案很明确。JavaEE提供的大多数服务都需要JavaEE容器。

• 用JavaSE可以做什么，而用JavaEE不能做什么？ 嗯...我不知道

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

• 开发人员何时决定不需要JavaEE？ 请参阅先前的答案。

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

从鸟瞰的角度来看，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 EE可以做什么，而用标准Java却不能呢？

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

人们可以用标准Java做什么，而用Java EE无法做什么？

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

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

一般而言，Java EE API解决了企业计算中常见的重复性问题。如果您有此类问题，通常使用标准解决方案是合理的；但是，如果您有其他问题，则可能需要使用不同的解决方案。例如，如果您需要与关系数据库对话，则应考虑使用JPA。但是，如果您不需要关系数据库，JPA将无济于事。

什么是Java EE？

让我们从Wiki的经典定义开始：

Java平台，企业版或Java EE是Oracle的企业Java计算平台。该平台提供了一个API和运行时环境，用于开发和运行企业软件，包括网络和Web服务以及其他大规模，多层，可伸缩，可靠和安全的网络应用程序。

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

Java EE需要什么？

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

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

为什么需要操作系统？因为在硬件方面有很多痛苦的工作，所以我们需要做一些简单的应用程序。如果没有操作系统，则需要一次又一次地执行。过于简化的OS只是一个程序容器，它为我们提供了运行应用程序的全局上下文。

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

这里的另一个示例可能是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总是在技术命名和版本控制方面遇到麻烦。因此，这种情况也不例外。

Java EE全部涉及容器概念。
容器是一个执行上下文，在该上下文中将运行您的应用程序并为其提供最后一组服务。每种服务均由名为JSR的规范定义。例如，JSR 907，JTA（Java事务Api）提供了一种针对不同资源管理分布式事务的标准方法。因此，要利用Java EE，您需要在容器中运行应用程序。EJB和servlet容器是两个主要的容器，它们都存在于任何Java EE认证的应用程序服务器上。
对于给定的JSR，通常有许多不同的实现，您将使用的实现取决于容器提供程序，但是您不必担心，因为您可以确定行为遵循预定义的约定：JSR API。

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