Java EE, Saviours and Frozen Time...

We've mentioned TomEE in the near past. Led by powerhouse developer David Blevins, it is a very exciting initiative that takes Tomcat and integrates all the necessary APIs to make it a fully certified Java EE 6 Web Profile offering. It makes Java EE a real possibility for developers focused on Tomcat.

Recently InfoWorld published an article on TomEE (to jog your memory these are the same fine folks that recently repeatedly declared Java dead because of the security vulnerability essentially limited to Applets). While most of the content of the article is very good thanks to David, some pretty curious views on Java EE got infused by the InfoWorld writer. Apparently, Java EE is frozen in time, something only people in gray cubicles care about and TomEE is Java EE's only hope for survival. It did not take very long for David to distance himself and TomEE from the article.

Some of us clearly see things a bit differently than InfoWorld (and suspect that most of you do as well). Specifically, I thought it's useful for you to consider the following few points as food for thought:

  • Pound-for-pound, the amount of innovation in Java EE and it's ecosystem rivals pretty much any other technology stack out there. Just some innovations one could mention is delivering the Java community from XML, configuration and jar hell using annotations, intelligent defaults and convention-over configuration, the radically reimagined EJB 3+ API,  Facelets, the CDI API, JAX-RS, Servlet 3, Bean Validation, the transformations in JMS 2, WebSocket and so on. There have been few significant technologies in the ecosystem that have not directly benefited from or outright adopted these changes. It's easy to see the scale of changes even from my very high level talks on Java EE 6 and Java EE 7. As a result, Java EE today is easily one of the most productive and powerful development platforms around.
  • Continued strong Java EE adoption in the community is a change that's here to stay. Even some organizations that once outright dismissed Java EE have now brought it back into their evaluation cycles. Our GlassFish stories, complete with videos are a nice concrete manifestation of this.
  • The JCP is a far different animal than what it was just a few years ago. The level of openness and ongoing reform geared towards reaching out to the average developer is patently obvious to folks like me and many others that have worked within the JCP as independents in recent years. You can see the end results in action from Arun's recent blog on JCP transparency and the adopt-a-JSR program that helps power it.
  • Java EE today is far more than just WebSphere 5 and WebLogic 9. There are options to suit any particular organization's needs such as GlassFish, JBoss, Resin and of course TomEE just to name a few. Even WebSphere and WebLogic have gone through wholesale changes thanks to modularity solutions like OSGi and  the Web Profile. The changes are not difficult to see if you look at things like the WebSphere Liberty Profile.

Perhaps my fellow Java EE/GlassFish comrade John Clingan said it best in his blog entry on the InfoWorld article - what is truly frozen in time is the idea that Java EE is the helpless damsel in distress waiting for a knight in shining armour to save her...

Comments:

Oracle, like our columnist Andrew Oliver, is certainly entitled to its own belief as to Java EE's relevance and strengths. But I do take exception to a factual error in this Oracle post, especially as the point of the post is to insinuate inaccuracies in the InfoWorld article rather than the differing judgments that they rally are: Oracle claims InfoWorld said Java is dead. That is completely false. I wrote the article that this false statement is purportedly from, and what I wrote was that client-side Java should be killed. Please criticize us if you disagree with our opinions, but don't say we said things we have not.

Posted by guest on March 29, 2013 at 01:30 PM PDT #

Quoted verbatim from prominent positions on InfoWorld articles - "Has the tipping point for Java finally come?", "How to kill Java dead, dead, dead". Hyperbole? Poetic license? Nonsense? Freudian slip? Attention getting? You be the judge...

BTW, the opinions here including on InfoWorld journalistic quality, are mine, not Oracle's.

Posted by Reza Rahman on March 29, 2013 at 02:32 PM PDT #

You mentioned that the JaveEE innovations deliver us from the "jar hell". Could you be more specific which technology you're referring to? I think that's one of the big issues JaveEE still has not solved (even with maven/ivy/gradle).

Posted by va on March 29, 2013 at 04:40 PM PDT #

One of the best write-ups on this point to-date is actually from a very smart GlassFish adopter named Harald Wellmann on his blog entry titled "Deconstructing Spring myths": http://hwellmann.blogspot.com/2012/05/deconstructing-spring-myths.html . It's in the context of a much broader topic so you'll have to be patient and read through the prose until you hit the Jar Hell section towards the midlle of the page. Do let me know if you still have trouble groking it - perhaps it's best I write something up on my personal blog on the topic.

Now, it's clear you are interested in cases where a very large number of third-party dependencies are unavoidable or you have very sophisticated modularity needs in your own application code. It's true Java EE does not directly address this requirement yet and it could in fact solve it for the Java community once-and-for-all in a way that OSGi simply can't. Today, the answer is to use the non-standard modularity solutions built into most modern application servers (most are OSGi based).

Since you ask the question, I am guessing what I'll say next won't sit well with you but it is the truth the way I see it personally after much soul-searching :-). My current view is that this requirement is more vendor-driven than anything most rank-and-file developers care about. For most folks, build-time dependency management ala Maven seems to be good enough.

The best way to get a proper handle on this issue is really to do a broad based survey like we did for Java EE 7: https://blogs.oracle.com/reza/entry/java_ee_7_survey_results . I hope to do something like that again once we wind down Java EE 7 and start work in earnest on Java EE 8.

Hope this helps.

Posted by Reza Rahman on March 30, 2013 at 08:20 AM PDT #

Thanks for your response. You're right, I was talking about lots of 3rd party libraries with their 5 levels of dependencies brought in by maven. I guess I was hoping there is some magic bullet solution that I was not aware of ... :-)

Posted by va on April 05, 2013 at 06:02 PM PDT #

Unfortunately, not as such and I'm not sure even OSGi flavored solutions help all that much. I always recommend carefully evaluating the value of adding yet another dependency to one's code.

Posted by Reza Rahman on April 06, 2013 at 08:28 AM PDT #

Post a Comment:
Comments are closed for this entry.