Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Ghosts of Java EE 7 in Production: Past, Present and Future

DZone's Guide to

The Ghosts of Java EE 7 in Production: Past, Present and Future

Hear Reza Rahman's perspective on the viability of using Java EE 7 in production and some of the history and debates that have swirled around enterprise Java.

· Java Zone
Free Resource

Never build auth again! The Okta Developer Platform makes it simple to implement authentication, authorization, MFA and more in Java applications. Get started with the free API.

         "First they ignore you, then they laugh at you, then they fight you, then you win."

  – Mahatma Gandhi

For those unfamiliar the three ghosts analogy comes from the Charles Dickens' classic A Christmas Carol. I hope the real message of the analogy is an entertaining but insightful literary puzzle for you to figure out, not to mention the far less imaginative opening quote largely along the same lines :-).

In the past few days I've seen a certain predictable group of folks on the Interwebs feigning concerns over the viability of using Java EE 7 in production. I have to be honest in that I think it is fairly obvious these concerns are more -ahem- opportunistic than sincere or well-intentioned. Nevertheless I think this is a great trigger to discuss something valuable to the Java EE community anyway - Java EE 7 production adoption in the near past, present and near future. In fact to be perfectly honest we have been deliberately covering these themes all along in various ways and foresee a useful purpose in revisiting them frequently going forward far beyond this one blog entry. Being responsible sentinels for the Java EE community has never demanded anything less.

The Prelude - Java EE 6 and Java EE 7
Most folks out there seem to hold the Java EE 6 release in high regard. I definitely agree the release was an important turning point for Java EE. While Java EE 7 is not a profound architectural paradigm shift in the way Java EE 5 and Java EE 6 was, it's significance is in the sheer amount of changes it contains. Java EE 7 is very easily the largest set of changes the platform has ever experienced. To boot we try to never make frivolous changes to the platform so each of these changes are all rather important to their respective users. To understand the scale and significance of these changes, you need not look much farther than my Java EE 7 slide deck. It is a very high level talk that I still struggle to fully deliver in 50-60 minutes after delivering it many times.

Let that last statement sink in for a moment. How many times have you been to a talk where a very experienced speaker struggles to cover even at a very high level the changes in a single update of any technology? I think that has not been true for a while by a large margin for any technology that tries to position itself as an alternative to Java EE - even if you take into account the total amount of changes in their albeit more frequent releases during an equivalent time period...

This has two important ramifications that's pretty much true of any significant open standard. For people that are paying any attention Java EE 7 is a very important update to adopt. If you apply a reasonably objective eye, it's clear many indeed are paying attention, already eagerly adopting Java EE 7 and will continue to do so in the near future. The flip side is that neither producing the standard nor a compatible implementation is a frivolous undertaking. Nonetheless if you apply a reasonably objective eye, it's clear all major implementors are in fact doing their part and will continue to do so in the near future.

The Ghost of Java EE 7 in Production Past
One of the most obvious tasks we have at this stage of the life of Java EE is to highlight successful adoption stories prominently and frequently (and yes, that means real world applications deployed to production). We have been doing just that for a long time now through the GlassFish stories blog, The Aquarium and JavaOne. We now have a helping hand in that very important task from none other than key Java EE advocate Adam Bien through his extremely popular blog. A central part of this task is you - Java EE adopters out there in the real world. And you have already stepped up beautifully. JavaOne 2014 was particularly fruitful in this regard enabling us to select a nice set of very well-attended real world Java EE 7 adoption stories.

Let that sink in for a second. These were people starting to use Java EE 7 in the real world within a year after it was released as a standard. You can as well and I'll discuss exactly how in a moment. If you want to take a closer look at these folks a great place to start is my former colleague Arun Gupta's very ironically on-point session titled Lessons Learned from Real-World Deployments of Java EE 7, which covers several adoption stories in a single session (clickthis link if you are having trouble seeing the embedded video):

Prolific Java EE blogger Abhishek Gupta did a very nice job summarizing all of the publicly shared Java EE 7 in production stories we have already, including those from Adam's blog. From my vantage point, this is merely the tip of the iceberg...

The Ghost of Java EE 7 in Production Present
If the Java EE 7 adoption stories that were submitted during JavaOne 2014 were good, the ones we are reviewing right now for JavaOne 2015 are great. Indeed the difficult choice this years is choosing which adoption stories to turn back - including ones from well-recognized national and global brands! You'll know in a few weeks who we picked if you stay tuned to this blog, the Aquarium or the JavaOne content catalog. For the ones we have to turn back, we will try and find a way to get their stories out to the community. The same applies to you as well. Hopefully this blog entry helps you understand why sharing your story has always been important for all server-side Java developers. Indeed I would encourage you to share your story even if you are using Java EE 6 today and not yet Java EE 7. Just drop me a note - I am not particularly hard to reach :-).

This now brings us to the question of what Java EE 7 implementations you have available to you now and in the very near future.

Your Platform Choices
At the end of the day Java EE is about allowing you to choose between compatible implementations and there are a lot to choose from. A quick look at the official Java EE compatibility page should make it amply clear to an objective eye that Java EE is unique in the degree of implementation choice and vendor-neutrality it allows.

For the purposes of brevity let's focus on what I'll very arbitrarily call the "big four" with regards to adopting Java EE 7 in production. I want to be very clear however that this distinction of "big x" is completely meaningless from the perspective of an open standard like Java EE that focuses on choice and the inherent fluid realities in our industry where anyone is a prince today and a pauper tomorrow. That being said I think these "big four" are sufficient for the purposes of this blog entry:

GlassFish: GlassFish is the reference implementation for Java EE 7. Consequently is it by definition the first to implement any Java EE version, just as GlassFish 4 was the first to implement Java EE 7. It used to be the case that Sun and Oracle also shipped GlassFish as a commercial product, including support. It is true that we no longer do that. However this does not mean that GlassFish is suddenly merely a toy. We've made it amply clear repeatedly that concerns like usability and security remain important. In fact that was the unequivocal message from our executive panel at JavaOne 2014. That was the whole point of the effort we put behind the GlassFish 4.1 release - after the announcement of the end of the commercial product line. Folks outside Oracle continue to contribute to the GlassFish code base - most notably the excellent Payara team that has long provided third party support for GlassFish. As a matter of irony, most GlassFish users have never paid for the commercial support from Oracle that is now apparently in vogue for some - I guess that is an story for another day...

WebLogic: One of the most astute questions posed to the GlassFish event executive panel at JavaOne 2014 was on plans for supporting Java EE 7 in WebLogic. Our executives provided a very candid answer to this question. Oracle's clear goal has been to minimize the time lag between a Java EE release and a fully supported WebLogic release to around half a year, including for Java EE 7 - not to mention Java EE 8.

Let that sink in for a second. That means implementing something as sizable as Java EE 7 not once, but twice, virtually concurrently. Only a company like Oracle would have the deep engineering resources to even consider such a goal. Clearly that was not a goal we have met this time, for sound technical and business reasons including the fact that WebLogic has always been far more than just Java EE. Indeed WebLogic is the engine behind Oracle's formidable cloud offering being built out even as we speak, not to mention the basic need of robustly enabling Java EE in the Oracle cloud. I can attest first hand that our engineers do whatever they can every day to meet all these important often competing goals expected of WebLogic including getting Java EE 7 in the hands of WebLogic developers.

Thanks to this hard work, WebLogic 12.2.1 with full support for Java EE 7 is slated to be released in just months (the officially sanctioned timeline states calendar year 2015 which means the end of this year at the latest). To put this in context, this is comparable to the time it required WebLogic to get certified against the much smaller Java EE 6 release!

In the meanwhile what we have done is release WebLogic 12.1.3 which supports some of the most significant Java EE 7 APIs developers ask for. The hard work to do this is not an academic exercise. The clear goal of this work is to allow developers to adopt Java EE 7 APIs as quickly as possible as we continue working hard towards WebLogic 12.2.1. Yet another legitimate pathway WebLogic customers have used successfully is to deploy their Java EE applications to GlassFish 4.x in the interim and then migrate to WebLogic at a later point.

WebSphere Liberty Profile: The Liberty Profile is an admirable and very courageous technical feat. It is essentially a modular Java EE application server written from scratch in the past few years. The Liberty team releases public monthly betas as well as incrementally supporting Java EE 7 APIs through their stable release supported in production. This means that you can start to use Java EE 7 APIs in production using Liberty 8.5.5 just as you can with WebLogic 12.1.3 in addition to starting to use Java EE 7 APIs in development using Liberty betas. If you take a look at the latest Liberty beta it is clear they too are just months away from fully supporting the full Java EE 7 platform. Again these efforts are not merely academic - they are intended to get Java EE 7 in the hands of developers are quickly as possible. Just as is the case with WebLogic, the Liberty Java EE 7 release timeline will be comparable to what it was for Java EE 6 even accounting for having to do more work building out on a brand new runtime code base!

WildFly/JBoss EAP: WildFly 8 has been fully Java EE 7 certified for more than a year now. In fact similar to GlassFish 4.1, WildFly 8.2 was an interim platform release and the WildFly team is now working on WildFly 9. Similar to the scenario with GlassFish and WebLogic, WildFly is not commercially supported by Red Hat but JBoss EAP is. Our usual suspect Java EE naysayers allude that this must mean WildFly is unfit for using Java EE 7 in production. This ignores two key factors. The first is that it is amply clear the WildFly team is highly responsive to the community, including fixing bugs in a timely fashion. The more important factor is historical context - WildFly is just a renaming of JBoss AS. It is no great secret that there has always been a sizable percentage of JBoss AS users that never paid for JBoss EAP for their production applications. There is little reason to believe that simply a renaming (and that is exactly what WildFly has been thus far) will change that dynamic significantly any time soon. Instead it's more likely a sizable amount of WildFly customers will use it for Java EE 7 applications in production just as they clearly do today.

For those that insist on Red Hat commercial support via JBoss EAP, it too is likely only months away. In fact, if EAP is released within this year (and there is little reason to believe it won't be), the JBoss EAP team would likely beat their timeline for supporting Java EE 6! Lastly, also similar to GlassFish and WebLogic, it has been a common strategy for Red Hat customers to start with JBoss AS (today's WildFly) and then move to a corresponding JBoss EAP version.

The Ghost of Java EE 7 in Production Future
I hope you've made it successfully through the sections above to finish our Java EE 7 in production journey through time. If you haven't, this is the section you want to pay the most attention to as it is here that we can take stock of what lies in the future.

If you are a reasonably optimistic individual that sees the glass as half-full, it should be clear that you already have quite a few options in terms of using Java EE 7 in production already including but certainly not limited to GlassFish and WildFly. But let's assume you are a little less of an optimist but not quite a complete pessimist that sees the glass as half empty. You too have several choices in beginning to use Java EE 7 in production - using GlassFish 4.x then switching to WebLogic 12.1.2, using WebLogic 12.1.3 and then switching to WebLogic 12.2.1, using WebSphere Liberty betas and then switching to Liberty 9, starting with Liberty 8.5.5 and then switching to Liberty 9 and finally using WildFly and then switching to JBoss EAP. I think that's quite a few ways as long as you have a little bit of will to back it up. Finally, let's assume you are a complete pessimist as our Java EE 7 naysayers seem to insist you should be. For you the future is this: in a few months more and by the end of this year at the latest you will have no less than half a dozen implementation choices to deploy your Java EE 7 applications to, most from some of the largest technology companies in the world. I hope the pessimist in you can see the fundamental value in that as opposed to being hostage to a single non-standard implementation with one commercial vendor.

Putting all of this in slightly broader context, the production use timeline for Java EE 7 is essentially equivalent to that of Java EE 6 for most users - with far more to offer and with the momentum of Java EE 6 behind us and with a clear, transparent long term road map for Java EE 8 ahead of us. As averse as I always am to predicting the future, I feel pretty comfortable to say we are yet to see many folks putting Java EE 7 in production in the near future if the past and present is any indication.

As to the perennial naysayers of Java EE, we've already proven them wrong once with Java EE 6. I have no doubt whatsoever we will prove them wrong again with Java EE 7. I am also equally certain they will declare us doomed once again when it comes time for the community to use Java EE 8 for their real world applications and many times on the way there. Where would be the sport of it all if they didn't :-)?

Please note that any views expressed here are my own only and certainly does not reflect the position of Oracle as a company

Build and launch faster with Okta’s user management API. Register today for the free forever developer edition!

Topics:
java ,java ee

Published at DZone with permission of Reza Rahman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}