I, along with several others, spent 6+ years at Oracle creating and nurturing the GlassFish community. ~852 blog entries on blogs.oracle.com/arungupta/tags/glassfish vouch for that. I still remember when our team got a presidential award at Sun Microsystems for growing the downloads from 0 to 5 million in 3 years. I was also popularly known as “GlassFish Guy” all around the world. Lots of fond memories …
I left Oracle and joined Red Hat a little over 4 weeks ago. Even though we have a competing (better project in WildFly and product in JBoss EAP but will always have high respect for GlassFish. It is the Reference Implementation as required by JCP and so by design will be always at the leading edge of technology. One of common myths I had to unravel all the time was that GlassFish can be used as a production application server because Sun/Oracle offered commercial support for it.
This was changed by Oracle’s announcement to abandon commercial support for GlassFish. Specifically …
Oracle will no longer release future major releases of Oracle GlassFish Server with commercial support – specifically Oracle GlassFish Server 4.x with commercial Java EE 7 support will not be released.
Commercial Java EE 7 support will be provided from WebLogic Server.
This means GlassFish will continue to be at the leading edge of technology (hopefully) but is now merely reduced to a toy. You can use GlassFish as a reference to ensure your code is using pure Java EE 7 APIs but any production deployments should seriously think twice before considering it as a choice of application server. This is also expressed by Antonio Goncalves:
GlassFish will stay open source. Yes, but with no commercial support it will not be used in organizations
Earlier today GlassFish plugin for Eclipse was removed from java.net. I suspect we’ll continue to see more news items like this making GlassFish truly for reference only.
This also means that today there are no vendors offering commercial support for Java EE 7 applications. Johan Vos from Lodgon jumped on the opportunity and offered commercial support for GlassFish. Johan (disclaimer: a great friend) is extremely knowledgeable about the internals and the codebase so he would be your good bet in case you want production support.
This decision from Oracle makes business sense as having two application server from one company is always confusing. This is the reason Sun (unfortunately) could not survive and Oracle will. David Blevins explained wonderfully in his post that open source isn’t free. In addition to WildFly, TomEE is the only open source application server that is now commercially supported by Tomitribe.
The announcement also said:
Oracle recommends that existing commercial Oracle GlassFish Server customers begin planning to move to Oracle WebLogic Server, which is a natural technical and license migration path forward
This would again make sense from Oracle’s perspective, at least for license, but not so much from customers or community perspective. Forester research analyst John Rhymer was quoted on that:
Folks that prefer GlassFish as their Oracle-supported production Java server now are looking at a big rise in costs
Agreed that Java EE is the common binding thread between the two application servers and there is some support for deployment descriptors across the two application servers. But that’s where the connection stops. Migrating an application from GlassFish to WebLogic is like migrating from one application server to another application server, and InfoQ agrees with that. They even said:
This needs more planning and effort, compared to moving to GlassFish with commercial support, or switching from WildFly to JBoss EAP.
Deployment descriptor interoperability is good to get started with but Markus Eisele explained in his blog entry R.I.P. GlassFish – Thanks for all the fish.:
Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.
Even if there is a knowledge of deployment descriptors but is that how the application will go into production as well ? What if support for GlassFish deployment descriptors is dropped from WebLogic ? Migrate again ?
Oracle also talks about shared code between GlassFish and WebLogic. If applications are built using standard Java EE APIs then the underlying implementations does not really matter much. Anyway most migration effort is associated with monitoring, management, clustering, and administration which is completely different between the GlassFish and WebLoigic servers. Customers estimating the level of effort to migrate away from GlassFish have the same analysis to perform for WebLogic or JBoss Enterprise Application Platform. Antonio also highlighted this aspect:
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)
Commercial GlassFish customers who want to explore a migration to WebLogic will need to evaluate the cost of both code and license migration. Oracle has not announced any license credit or reduced upgrade pricing for commercial GlassFish customers considering migration to WebLogic. The latest Oracle price list dated October 17, 2013 lists the per processor price of GlassFish at $5,000 and WebLogic Server Enterprise Edition at $25,000, you do the Math!
JBoss EAP calculator helps you compare ongoing subscription cost of JBoss EAP and upfront license and ongoing support/maintenance costs of WebLogic and WebSphere. As shown in the EAP calculator there is 92% savings using JBoss EAP over WebLogic over 3 years.
6 Facts blog talk about WebLogic is not always more expensive than Oracle GlassFish Server. The blog seems correct on the cost analysis but it does not mention that WebLogic Standard Edition does not offer any clustering and failover capabilities. That also makes the Standard Edition that much less attractive an offering. You get what you pay for!
WildFly is the bleeding edge innovation engine for Red Hat and JBoss EAP allows customers to consume open source with ease. If you are looking for an open source application platform with commercial support from a large vendor, then your only choice is Red Hat.
We are open and this is also stated in a very objective opinion from Sharat Chander (a great friend and my ex-colleague):
Here is one tweet that I saw after the announcement and we’ll continue to see more of these …
What can you do ?
- WildFly 8 is getting ready to be released and is passing ~99% TCK for Java EE 7 compliance. Make sure to try your applications on WildFly and report any bugs. Tech Tip #1 shows how to get started.
- Watch a Deep Dive into WildFly 8 and Java EE 7 webinar to learn more about WildFly 8.
- Download JBoss EAP and try your applications on it. You can always reach out to Red Hat Consulting if you need help with migration efforts.
- Try your Java EE 6 applications on OpenShift (deployed on JBoss EAP 6) or Java EE 7 applications using WildFly cartridge.
Red Hat and I are here to help!