Just what is Java EE really? [closed]
Solution 1:
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.
Solution 2:
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 implementations of 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 need JavaEE? 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".
Solution 3:
At bird's eye view, Java EE is a platform, i.e. something that we can build on.
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.
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).
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.
Why do I need something massive as JBoss just to compile simple code to send an email?
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.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Because only the APIs are standardized, not the implementations.
Why are there so many Java EE offerings
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?
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.
What can one do with standard Java that they cannot do with Java EE?
Nothing, since Java EE includes Java SE.
When does a developer decide they "need" Java EE? When does a developer decide they do not need 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.