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

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

如果有的话，它不是这样的很多应用程序服务器环境本身在这里受到威胁，但所有其他库的存在以及整合它们的集成代码。

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

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

这个问题存在一些问题：

1. 对于编译，您只需要API jar，Web配置文件小于1MB，完整配置文件小于1MB。


2. For运行你显然需要一个实现，但大规模是夸大事物。例如，OpenJDK约为75MB，TomEE（包含邮件支持的Web Profile实现）仅为25MB。甚至GlassFish（一个完整的配置文件实现）也只有53MB。


3. 邮件在Java SE（以及Tomcat）中运行得非常好，也可以使用独立的 mail.jar和activation.jar 。

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

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

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

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

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才是最新的。

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.

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)?

Thanks for helping me clear the flog!

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.

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.

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

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.

Why are Java EE libraries not "standard" and included in the regular JVM download and/or the 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?

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.

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)?

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.

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.

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

Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. 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.