“Oh Lord, won’t you buy me a Mercedes Benz” (or RIP GlassFish)

Disclaimer : I am a former BEA employee, former Weblogic consultant, author of three books based on GlassFish and use JBoss extensively. Today I’m self-employed and therefore do not belong to any company.

On the 4th of November 2013, Oracle announced the roadmap of GlassFish. It talks about version “4.1 scheduled for 2014“, alignment with Java EE 8 and so on… but the most important news are :

  • “Oracle will no longer release future major releases of Oracle GlassFish Server with commercial support
  • Commercial Java EE 7 support will be provided from WebLogic Server
  • Oracle GlassFish Server will not be releasing a 4.x commercial version
  • Oracle recommends that existing commercial Oracle GlassFish Server customers begin planning to move to Oracle WebLogic Server”

Like most of you, when Oracle bought Sun I thought GlassFish was going to die in favor of Weblogic. Years had past, both application servers were sharing more and more dependencies, and I was thinking that both would merge : GlassFish would remain, with dual licensing, sharing the goodies of Weblogic and the community of GlassFish. I was wrong.

This news brings several thoughts to me :

  • No commercial support means that GlassFish will become the good old J2EESDK, which is a Java EE reference implementation used only for playing
  • GlassFish is the RI and will always be the first app server to implement Java EE“, yes, and so what ? Organizations do not jump on a new app server just because a new EE release has been published, adoption takes time. Organizations want a good app server, not one that is just on time (being a RI is ok, having commercial support does the difference)
  • GlassFish will stay open source. Yes, but with no commercial support it will not be used in organizations
  • WildFly and JBoss have the same code base, GlassFish and Weblogic don’t (and that makes a huge difference between RedHat and Oracle app servers)
  • Customers move away from Websphere to go to GlassFish, JBoss or TomEE, not to Weblogic
  • The GlassFish community is vibrant, it is not with Weblogic (there is even a GlassFish User Group, can’t see any Weblogic user group around)
  • In this era of Cloud, organizations need lightweight and simple app servers to deploy massively
  • Google Trends tells me that Weblogic is going down compare to GlassFish, could that be true ?

If you compare IT with the car industry, Oracle’s vision is to sell luxury Mercedez Benz, not little-joe Ford : an expensive Cloud running an expensive Application Server, storing data in an expensive Database… while everyone else is doing the opposite.

Oracle never pushed GlassFish. I dealt with many Oracle sales guys who knew nothing about GlassFish, they were always trying to sell Weblogic licenses. Look at companies like Red Hat, they know how to make business around Open Source. A shame Oracle didn’t learn how to do it (it takes time but it’s doable).

All in all, this is a very bad news for GlassFish, bad news for Java EE and bad news for the community. The only thing that makes me feel happier, is that my friends from JBoss and TomEE will have even more attraction. Saying that, competition is good and brings innovation and robustness to the application server’s world. JBoss and TomEE have an Open Source DNA and Oracle doesn’t.

Oracle, I might be wrong, but I think you are betting on the wrong horse. In the meantime, RIP GlassFish.

Special thanks to Janis Joplin

Categories: Java

Tagged as:


  1. I share a lot of your thoughts. Especially, with medium organizations who don’t need nuclear weapons to run their business.

    The community could fork the glassfish repo but it takes energy to continue the work.

    When Oracle ate Sun few years ago, an Oracle development big boss came to Devoxx talk a bit about… nothing.
    He shared a picture of his desktop cause there’s nothing to say: now, Oracle is the Commander, everything is about money.

    So Oracle… what’s your next move ? killing *your* Java ?

  2. “If you compare IT with the car industry, Oracle’s vision is to sell luxury Mercedez Benz, not little-joe Ford : an expensive Cloud running an expensive Application Server, storing data in an expensive Database… while everyone else is doing the opposite.”

    This summarizes the whole story.

    Great +1

  3. Although I agree with some of your comments, there’s one that really bogus me: sharing same codebase (at some level) is irrelevant for companies that want to go serious on production.

    WildFly builds come from a different source code “tag” than JBoss EAP. The latter is WildFly codebase with several bug fixes (some not shared fairlessly with community) plus other features that Red Hat does not make clear.

    It is good to have two products coming from the same codebase, but this is not what matters for companies running critical applications in production. Do they have access to the source code? Yes. Does WildFly the community have access? No.

    When we are talking about production, serious business environments, it is the source code of the binary running on it that matters.

    • Bruno, I might not have been very clear. I don’t know the internals of WildFly vs JBoss, but my understanding is that JBoss == WildFly + QA – extra features (if someone could confirm, that would be better). So, the important thing with that, is that JBoss only has one engineering team to develop both. And that’s a big difference. Oracle acquired BEA, so they ended up with two different products, two different code base and two different teams. Maintaining two engineering teams is a huge investment (that’s also why Oracle is letting GlassFish go).

      So, really, what I’m saying is “same code” means “same developers team”

      • Actually, JBossAS 6.1 EAP (commercially supported) is currently based on JBossAS Community Editoin 7.x. WildFly, however, is a big rewrite internally (again!), based on Undertow which is entirely new.
        So technically, JBoss == WildFly + QA will only be true once we see JBoss 7 EAP based on WildFly. Until that time, it is not really true. (fingers crossed)

      • “WildFly, however, is a big rewrite internally (again!), based on Undertow which is entirely new.”

        This is not really true. Yes, we have introduced a new web server and rewritten the web subsystem as a result, but Wildfly contains ~30 subsystems, and well as a lot of core server code. Calling it a complete rewrite because of a new subsystem is a bit of a stretch.

    • (disclaimer: I am a Wildfly/JBoss EAP developer)

      JBoss EAP and Wildfly do share the same code base.

      Basically it is kinda like the difference between Red Hat Enterprise Linux and Fedora, Wildfly has a Fedora like model, and basically tries to always have the latest and greatest features (e.g. EE7, new non blocking web container).

      JBoss EAP is more RHEL, the core code base is the same, but features and bug fixes are back ported from Wildfly once they are deemed stable.

      Your comment about bug fixes not being shared with the community is not really true. In general all features and fixes have to go into Wildfly upstream first before they are allowed into EAP, the only exception to this is when the EAP fixes are no longer relevant to the Wildfly code base, e.g. Wildfly no longer has support for CMP so all CMP fixes are EAP only.

  4. Nice post.
    I hadn’t understand this: “WildFly and JBoss have the same code base, GlassFish and Weblogic don’t”, but you explained: “So, really, what I’m saying is “same code” means “same developers team””


    • FYI, the same team also develops GlassFIsh and WebLogic. The development teams have been integrated for a while now. This is driven both by the large amount of shared code and by domain expertise.

  5. Good overview of the situation Antonio–I guess Arun saw this even earlier. When you write this “Customers move away from Websphere to go to GlassFish, JBoss or TomEE, not to Weblogic”, where are you seeing this occur, and by what methods are you tracking it? Or is this more of a gut feel (and one I would tend to agree with just based on conversation). See you at Devoxx 🙂

    • I work mostly with banks, finance, insurance, institutions… Most of them have been using WebSphere for years and tend to move out from it. Some go to Tomcat, but most of it go to JBoss.
      Big companies are ok to use open source software… but they need commercial support, otherwise, they won’t do it. Without commercial support, an application server is useless. We are not talking about an “open source logging library”, we are talking about an application server : the heart of companies’ business.

  6. On the Oracle website, we can read that :
    – “The trunk will eventually transition to GlassFish Server Open Source Edition 5 as ****a**** Java EE 8 implementation.”
    – “The Java EE 8 Reference Implementation ****will be derived from**** GlassFish Server Open Source Edition 5.”

    The way I understand this differs from yours : Glassfish 5 is not going to be the RI of JavaEE 8. Is it correct ?

  7. This is IMHO, an odd decision.

    If GF was not the RI, the only consequence would be that people would “just” shift to an alternative solution that is both opensource and commercialy supported.

    But GF is also the RI. Hence, this is also a bad signal : Oracle does not commercialy support the RI of a keystone specification. So the people will simply ask “why ?”. I can already hear rant out of this question.

    Either Oracle plan is to simply drop GF in the middle term, or I don’t get the idea behind droping the support. Oracle do not cut dev cost but cut the money source to finance it.

    Odd IMHO and a bad signal anyway.

  8. Hello antonio,

    i find your post rather excessive on some point.

    “Java EE reference implementation used only for playing”

    Glassfish like other EE server is built with many open source components which are ready for production. So if i follow your thought about this : JSF Mojarra is not ready for Production, Hibernate Validator is not ready for P, JEE 7 Batch / Spring Batch is not ready for P, JAX-RS Jersey is not ready …,

    Really ???

    “GlassFish will stay open source. Yes, but with no commercial support it will not be used in organizations” :

    Can you name one open source server with commercial support by the editor ?
    JBoss EAP is not open source for instance.

    Most organizations use dozen of open source components without any kind of support. Look at Tomcat for instance ? Eclipse ? Postgresql ?

    “Organizations do not jump on a new app server just because a new EE release has been published” : Yes, but doing JEE development on a non certified JEE server is a major risk, using the RI mitigates the risk, even if you don’t use all JEE new stuff, the old one continue to work.

    “WildFly and JBoss have the same code base, GlassFish and Weblogic don’t” : RedHat don’t tell that.

    The real questions about this story are :

    Does Oracle will continue to keep Glassfish as the RI ?

    If so :

    Does Oracle will seriously continue to enhance the Glassfish Open Source version on non JEE matters ?

    Administration console, clustering ,…

    Best regards.

    • Yes, most of the Java EE pieces are production ready (as you said, Mojarra, Hibernate Validator…). But an application server is the glue between all those pieces. There are no SPI in most of the EE specs, so bundling one with the others can be quite complex. GlassFish and Weblogic share some pieces (e.g. Mojarra) but GlassFish and Weblogic are really different because the glue is different.

      Funny enough, I just worked for a big company who bought support for Tomcat. What I’m concern is the code base. You say that JBoss EAP is “not open source”, but it shares most of the code from WildFly (which, again, is not the case between GlassFish and Weblogic). The team between WildFly and JBoss is more or less the same. WildFly is just the code of JBoss (minus QA) plus a few extras (it’s the JBoss sandbox). Which is not the case between GF and WLS.

      Does Oracle will continue to keep GF as the RI ? Yes, of course, they have to. The Spec Lead of Java EE (Oracle) MUST have an RI (so even if in the future this RI is not called GF anymore, it would have to be called something else). So, Oracle will keep on investing time, money and effort in a RI… but without having any financial benefits (because no commercial support). So GF will do the minimum (implementing Java EE, because it has to) without any extra development (admin console, clustering… will disappear or be very very basic).

      Again, my 2 cents

      • Maybe, Glassfish will turn into a minimalistic JEE server on non JEE matters : it will probably do the job for many organizations.

        Tomcat is the most used java web container, and how good are the non JEE features ?

        So what ? It’s will be very nice for many people.

        The minimal glue will probably do the job : most JEE features are not in the glue but in the JEE components (Weld, Mojarra, Jersey, Metro, …)

        As you say, the community is vibrant so maybe open source projects will emerge on such matters : like it does with Tomcat.

        Yes, some company does Tomcat support, but : does the patch are integrated into the Tomcat Trunk ?

        If not that’s a fork of Tomcat, this not really the same. If you change the support company you have no guarantee they will endorse the previous patches.

        Yes, i would like Oracle to continue the current business model, i share your disappointment … but your post is very hard on RI components. Some people may think you have to pay to get a Java web application in production.

      • > admin console, clustering… will disappear or be very very basic).

        Maybe clustering should be added to the spec then 😉

    • > JBoss EAP is not open source for instance.

      This is incorrect. JBoss EAP is still fully open source. It’s LGPL and Red Hat does not fully own all copyrights as far as I know and can’t dual license it.

      What the LGPL allows and doesn’t allow should be well known. Since JBoss EAP is still LGPL it can’t take away any rights granted under this license. All EAP source code is publicly and freely available on the Red Hat FTP site.

      > doing JEE development on a non certified JEE server is a major risk

      I agree, but unfortunately the TCK is far too incomplete to state it the other way around. A certified server NEVER means that the server is suitable for production! See eg how very early and buggy versions of JBoss got fully certified.

  9. JBoss EAP = JBoss Community + (critical fixes for production)
    (see http://www.jboss.org/jbossas/faq)

    So for production buying EAP is the only choice. Not a big deal as many companies want commercial support, but it means that JBoss looks more and more like WebSphere/Weblogic and less and less like Glassfish/TomEE. Companies buying JBoss EAP are at the mercy of Redhat sales guys… and they can’t use a ‘we will go with no support version’ strategy to negotiate…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s