What's in a name? Java EE? J2EE?

“What’s in a name? that which we call a rose
By any other name would smell as sweet.”

- William Shakespeare

Yes, what’s in a name, you might ask ? Java EE or J2EE? Why does it matter? After all, both names refer to the Java technology stack used to build distributed enterprise applications. . right? Maybe not so right . . . . .

I am not sure if it is just me, but in many of the interviews I have conducted, I have often seen that the candidates do not seem to be able to recall the exact version of J2EE or Java EE they have worked with ? What they is certainly sure about, is the fact that the technology name is J2EE ;-) For instance, they might say that they have experience developing applications on Weblogic 11g, but they are stuck with J2EE in their heads (and their resume of course), being unaware of the fact that they are already using Java EE 5 and its features via Weblogic 11g. As far as Java SE is concerned, the candidate, more often than not, is able to successfully enumerate the exact versions of the platform he has worked with.

I get a feeling that the ’2′ has stuck primarily due to the previous Java SE Platform nomenclature - J2SE1.x.

IMO, the distinction b/w Java EE and J2EE can be exemplified in a simpler way without getting into the finer details and debates w.r.t APIs, specification etc

Ask yourself the following questions (try pondering about these before peeking into my answers below)

1. Did J2EE allow us to build applications without using external frameworks like Struts, Spring, Hibernate etc?
2. Did J2EE allow us to decorate our code with appropriate metadata and allow the server to automatically understand it and weave its magic?
3. Did J2EE allow us to deploy a POW (Plain Old WAR) without any XML configuration and expect everything to work perfectly?
4. How were EJBs developed in the year 2005 and before, with J2EE? How many interfaces? What about XML configurations?
5. How would we have integrated with client side frameworks like AngularJS using pure vanilla J2EE?
6. In the J2EE era, what would you do back if you wanted your web site to serve real time data to ALL the clients connected to it? A stock trading application, a bidding web site . . . . . ???

Answers

1. No . . loud and clear. How about Java EE 7? With 32 standards specificationsand related APIs divided between Web layer (JSF, Servlets, WebSockets. JSON-P etc), Business layer (EJB, JMS, JPA, CDI etc), Integration layer (JAX-RS, JAX-WS), one need not venture into any framework. Just use Java EE 7 out-of-the-box. No external dependencies, no learning curve for new frameworks. no JAR hell . . pure Java EE stack.
2. No . . there were no annotations in J2SE 1.4 and hence J2EE 1.4. It was all about XML and more XML. How about now? It is CoC based – Convention Over Configuration. Hardly any XML. POJO + Annotations = Magical Bean. See this presentation by Reza Rahman (Java EE/GlassFish evangelist at Oracle)
3. Just a WAR file? Are you kidding me? What about EARs, EJB JARs within EARs, WARs within EAR, JARs within JARs etc etc? Now? It is entirely possible and the ideal way to go. I am not going to force you to believe me. You can trust David Blevins from Apache TomEE though ;-) Listen to his talk (skip to 4:40)
4. I am scared to even write about this – in case you do not know the answer to this, it’s probably the best for you! Trust me. . . Now? EJB 3 onwards – for a simple Session bean, the @javax.ejb.Stateless annotation is all you need. No interface needed . . EJBs should be renamed to EEJB – Easy Enterprise Java Beans!
5. A ready made API, available out-of-the-box, based on HTTP principles (protocol of the web) – none other than JAX-RS. Learn more here
6. Polling, long polling, Comet, Atmosphere etc etc etc? Now? Thanks to the WebSocket API in Java EE 7, the solution is a POJO annotated with@javax.websocket.ServerEndpoint along with annotated callback style methods to handle business logic. Learn more about WebSockets from this talk from Daniel Coward

How about a catchy alias for Java EE . . to set it apart ?

I am not sure if Java EE has a catchy alias, akin to it’s Java SE equivalent. Tiger, Mustang and Dolphin were selected names for Java SE 5, Java SE 6 and Java SE 7 respectively. I think that can really help

Conclusion

Unfortunately, Shakespeare’s analogy does not apply in this scenario. J2EE was and never will be as sweet and Java EE 7 and its successors (wait till you see Java EE 8). What’s important is to realize that J2EE refers to the Enterprise Edition of Java prior to Java SE 5 i.e. during the J2SE 1.4 era. It’s obvious that the name J2EE brings back a few unwanted memories – XML Hell, multiple interfaces for one simple EJB, a few verbose APIs etc etc.

The world has changed since the J2EE era, requirements have changed, Java SE has evolved and so has J2EE – it’s now Java EE (has been since May 2006). That is why it is important not to casually throw around the term J2EE when one actually means Java EE e.g. look at this!Of course, when you are actually referring to versions prior to Java EE 5, J2EE is the appropriate word

Let us embrace and rejoice the change, and remember, that in the Java world, there is a lot in a name ;-)

Excited about Java EE? I suggest you explore Java EE 7 (if you haven’t already) . Maybe you can visit My Java EE 7 page on ZEEF ? ;-)