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:
- 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.
- 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.
- 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.
