Java EE 到底是什么？

Just what is Java EE really?

提问by SnakeDoc

Java EE has this "mysterious shroud" around it for younger Java developers - one that I've been trying to lift myself for quite a while with little success.

Java EE 为年轻的 Java 开发人员提供了一个“神秘的保护罩”——我已经尝试提升自己很长一段时间但收效甚微。

Confusion arises from:

混乱源于：

• Java EE seems to be both a library and a platform - there are multiple ways to "get" the Java EE library, typically from something like Oracle's Java EE SDK download. However, the Java EE library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc). Why? Can't the libraries function outside of the application server environment? Why do I need something massive as JBoss just to compile simple code to send an email?

• Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?

• Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?

• What can one do with Java EE that they cannot do with standard Java?

• What can one do with standard Java that they cannot do with Java EE?

• When does a developer decide they "need" Java EE?

• When does a developer decide they do not need Java EE?

• Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)?

• Java EE 似乎既是一个库又是一个平台——有多种方法可以“获取”Java EE 库，通常来自 Oracle 的 Java EE SDK 下载。但是，除非您的代码正在 Java EE 应用程序服务器（例如 JBoss、GlassFish、Tomcat 等）上运行或有权访问 Java EE 应用程序服务器，否则 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）不同步？

Thanks for helping me clear the flog!

谢谢你帮我清除鞭子！

采纳答案by Arjan Tijms

Why can't the libraries function outside of the application server environment?

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

Actually they can. Most of the libraries can be directly used standalone (in Java SE) or included in a .war (practically that's nearly always Tomcat). Some parts of Java EE, like JPA, have explicit sections in their respective specifications that tells how they should work and be used in Java SE.

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

If anything, it's not so much an application server environment per se that's at stake here, but the presence of all other libraries and the integration code that unites them.

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

Because of that, annotations will be scanned only once for all your classes instead of every library (EJB, JPA, etc) doing this scanning over and over itself. Also because of that, CDI annotations can be applied to EJB beans and JPA entity managers can be injected into them.

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

Why do I need something massive as JBoss just to compile simple code to send an email?

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

There are a few things wrong with this question:

这个问题有几个问题：

1. For compiling you only need the API jar, which is below 1MB for the Web Profile, and a little over 1MB for the full profile.
2. For running you obviously need an implementation, but "massive" is overstating things. The OpenJDK for example is around 75MB and TomEE (a Web Profile implementation containing mail support) is only 25MB. Even GlassFish (a Full Profile implementation) is only 53MB.
3. Mail works perfectly fine from Java SE (and thus Tomcat) as well using the standalone mail.jar and activation.jar.

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

Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?

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

Java EE in a way was one of the first attempts to split up the already massive JDK into chunks that are easier to manage and download. People are already complaining that the graphical classes (AWT, Swing) and Applets are inside the JRE when all they do is run some commands on a headless server. And then you also want to include all the Java EE libraries in the standard JDK?

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

With the eventual release of modularity support we'll just have a small base JRE with many things separately installable as packages. Perhaps one day many or even all classes that now make up Java EE will be such package as well. Time will tell.

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

Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?

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

There are more than just two flavors of Java SE. There is at least the IBM JDK, the previous BEA one (JRocket, which is being merged into the Oracle/Sun one because of the acquisition), various other open source implementations and a slew of implementations for embedded use.

Java SE 有不止两种风格。至少有 IBM JDK、之前的 BEA（JRocket，由于被收购而被合并到 Oracle/Sun 中）、各种其他开源实现和大量嵌入式实现。

The reason behind Java SE and EE being a specification is that many vendors and organizations can implement it and thus it encourages competition and mitigates the risk of vendor lock-in.

Java SE 和 EE 成为规范的原因是许多供应商和组织可以实施它，因此它鼓励竞争并降低供应商锁定的风险。

It's really no different with C and C++ compilers, where you have many competing offerings as well all adhering to the C++ standard.

C 和 C++ 编译器确实没有什么不同，在这些编译器中，您有许多竞争产品，并且都遵循 C++ 标准。

Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)

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

Java EE builds on Java SE, so it trails behind. The versions do correspond though. Java EE 5 requires Java SE 5. Java EE 6 requires Java SE 6 and so on. It's just that mostly when Java SE X is current, Java EE X-1 is current.

Java EE 建立在 Java SE 之上，所以它落后了。版本确实对应。Java EE 5 需要 Java SE 5。Java EE 6 需要 Java SE 6 等等。只是当 Java SE X 是最新的时候，Java EE X-1 是最新的。

回答by jahroy

Here are a few quickly composed answers to your questions...

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

• Why can't JavaEE libraries function without an application server?The services provided by JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) inherently involve JavaEE compliant Application Servers (for example: GlassFish, JBoss, WebSphere, etc...). Therefore the JavaEE libraries serve no purpose without such a container. "Why do I need something as massive as JBoss just to compile simple code to send an email?" You don't. There are ways to send an email without JavaEE... But if you want to do it the JavaEE way, you need a JavaEE container.

• Why are JavaEE libraries not included with JavaSE download?The same reason that many libraries aren't included: it would be overkill. Since you can't even use the JavaEE libraries without an application server, why bother to include them? JavaEE should be downloaded if and when a developer installs an application server and decides to use JavaEE.

• Why are there so many JavaEE offerings?Are there really "so many" JavaEE offerings? If so, please list some of them. More accurately I believe there are multiple implementationsof the same APIs.

• What can one do with JavaEE that they can't do without standard Java?Lots. You can't rely on an application server to manage transactions or persistence contexts without JavaEE. You can't allow an application server to manage EJB dependency injection without JavaEE. You can't use an application managed timer service without JavaEE. The answer to this question should make the answer to the first question quite clear... Most of the services provided by JavaEE require a JavaEE container.

• What can you do with JavaSE that you can't do with JavaEE?Um... I don't know.

• When does a developer decide they needJavaEE?This question is completely subjective... But if you need any of the services provided by JavaEE, you start to think about it. If you don't know what JavaEE is... you probably don't need it.

• When does a developer decide they do not need JavaEE?See previous answer.

• Why is JavaEE library version not in sync with JavaSE version?Good question. I won't pretend to know how to answer it... But I would guess the answer is: "because they're not in sync".

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

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

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

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

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

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

• 开发人员何时决定不需要 JavaEE？见上一个回答。

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

回答by meriton

At bird's eye view, Java EE is a platform, i.e. something that we can build on.

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

Taking a more technical perspective, the Java Enterprise Edition standard defines a set of APIs commonly used for building enterprise applications. These APIs are implemented by application servers - and yes, different application servers are at liberty to use different implementations of the Java EE APIs.

从技术角度来看，Java 企业版标准定义了一组通常用于构建企业应用程序的 API。这些 API 由应用服务器实现 - 是的，不同的应用服务器可以自由使用 Java EE API 的不同实现。

However, the java ee library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc).

但是，除非您的代码正在 Java EE 应用程序服务器（例如 JBoss、GlassFish、Tomcat 等）上运行或有权访问 Java EE 应用程序服务器，否则 java ee 库将不起作用，也无法编译。

You compile against the Java EE APIs, so you only need those APIs at compile time. At runtime, you'll also need an implementation of these APIs, i.e. an application server.

您针对 Java EE API 进行编译，因此您在编译时只需要这些 API。在运行时，您还需要这些 API 的实现，即应用服务器。

Why do I need something massive as JBoss just to compile simple code to send an email?

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

You don't. However, if you wish to use the Java EE API for sending mail, you will need an implementation of that API at runtime. This can be provided by an application server, or by provided by a stand alone library you add to your classpath.

你没有。但是，如果您希望使用 Java EE API 发送邮件，则需要在运行时实现该 API。这可以由应用程序服务器提供，也可以由添加到类路径的独立库提供。

Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?

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

Because only the APIs are standardized, not the implementations.

因为只有 API 是标准化的，而不是实现。

Why are there so many Java EE offerings

为什么有这么多 Java EE 产品

Because people disagree on the right way to implement certain features. Because different vendors compete for market share.

因为人们对实现某些功能的正确方法存在分歧。因为不同的供应商争夺市场份额。

What can one do with Java EE that they cannot do with standard Java?

使用 Java EE 可以做哪些标准 Java 无法做的事情？

Since Java EE implementations are built with "standard Java": Nothing. However, leveraging the existing libraries can save a great deal of effort if you are solving typical enterprise problems, and using a standardized API can prevent vendor lock-in.

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

What can one do with standard Java that they cannot do with Java EE?

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

Nothing, since Java EE includes Java SE.

没有，因为 Java EE 包括 Java SE。

When does a developer decide they "need" Java EE? When does a developer decide they do not need Java EE?

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

Generally speaking, the Java EE APIs solve typical, recurring problems in enterprise computing. If you have such problems, it usually makes sense to use the standard solutions - but if you have different problems, different solutions may be called for. For instance, if you need to talk to a relational database, you should consider using JPA. But if you don't need a relational database, JPA won't help you.

一般来说，Java EE API 解决了企业计算中典型的、反复出现的问题。如果您遇到此类问题，通常使用标准解决方案是有意义的 - 但如果您遇到不同的问题，则可能需要不同的解决方案。例如，如果您需要与关系数据库对话，您应该考虑使用 JPA。但如果您不需要关系数据库，JPA 将无济于事。

回答by Maxim Kolesnikov

What is Java EE?

什么是 Java EE？

Let's start from canonicity definition at wiki:

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

Java Platform, Enterprise Edition or Java EE is Oracle's enterprise Java computing platform. The platform provides an API and runtime environment for developing and running enterprise software, including network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network applications.

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

The main point here is that Java EE is a platform provides an API, not some concrete library.

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

What for Java EE needed?

Java EE 需要什么？

The main scope of Java EE is the network based applications, unlike Java SE oriented to the desktop applications development with simple network support. This is the main diference between them. Scalability, messaging, transactioning, DB support for every application... the need in all of this has increased with the evolution of the network. Of course a lot of ready solutions which Java SE provides are useful for network development, so Java EE extends Java SE.

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

Why do we need application servers to run our code?

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

Why do we need operation systems? Because there are a lot of painful work with hardware we need to do to make even simpliest application. And without OS you need to do it again and again. Oversimplified OS is just a programmatic container, which provides us a global context to run our applications.

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

And this is what the application servers are. They are allows us to run our applications in their context and provides us a lot of highlevel functionality which is needed for enterprise highloaded network applications. And we are don't want to write our own bicycles to solve this problems, we are want to write code which will satisfy our business needs.

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

Another example here could be JVM for Java.

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

Why Java EE doesn't contains onboard app server?

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

Hard to say for me. I think, it was done for more flexibility. Java EE says what they should do, they decide how to do it.

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

Why JVM doesn't include Java EE?

为什么 JVM 不包含 Java EE？

Because they directed to different market sectors. Java EE has a bunch of functionality which is doesn't need for usual desktops.

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

Why are there so many Java EE offerings?

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

Because Java EE only describes the behaviour. Everybody can implement it.

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

What can one do with Java EE that they cannot do with Java SE?

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

To conquer the internet. It's really hard to do with Java SE applets and sockets :)

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

What can one do with Java SE that they cannot do with Java EE?

用 Java SE 可以做什么而不能用 Java EE 做什么？

As mentioned above Java EE extends Java SE, so with Java EE you should be able to do everything what is available for Java SE.

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

When does a developer decide they "need" Java EE?

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

When they need the power of Java EE. All what is mentioned above.

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

When does a developer decide they do not need Java EE?

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

When they write a usual console or desktop application.

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

Why versions of Java SE and Java EE are unsynced?

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

Java always had troubles with it's technologies naming and versioning. So this situation is not an exception.

Java 在它的技术命名和版本控制方面总是遇到麻烦。所以这种情况也不例外。

回答by Gab

Java EE is all about container concept.
Container is an execution context within which will run your application and which provide this last a set of services. Each kind of service is defined by a specification named JSR. For example JSR 907, JTA (java transaction Api) which provide a standard way to manage distributed transaction against different resources.
There are generally many different implementations for a given JSR, the implementation you will use depends on the container provider, but you don't really mind about that as you are sure the behavior respect the predefined contract : the JSR API.
So to take advantage of Java EE, you need to run your application inside a container. The two main ones are EJB and servlet container which are both present on any Java EE certified application server.

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

The aim of all of this is to defined a standard execution environment to allow to package your application with only the essentials, id.est. your business. It avoids to depend on a unknown and various set of third-party libraries that you would have to package and provide with your app otherwise, and which may be sources of conflict with other apps on the server. In Java EE you know that all standard non functional requirements like security, transaction, scalability, remote invocation, and many more will be provided by the container (factorized for all apps running inside it) and you just have to base your work on its.

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