Glassfish Is Now A JavaEE Toy
If you are using Glassfish in production, as we are, you probably know that Oracle won’t provide any commercial support for Glassfish 4 and beyond. They will keep supporting Glassfish 3.x for a short period of time, but they will push those customers to migrate to WebLogic from now on.
If you are an open source supporter, as we are, you’re probably very upset. We know this Oracle’s move helps to diminish the sustainability of the open source business model. It shows that the replacement of an open source product by a proprietary one is worth doing it. Well, sometimes, this is just incompetence of the sales team and/or product manager to read signs from the community and from the market to achieve better results. Maybe, it didn’t happened to Oracle because they simply don’t understand the open source business at all. We can easily list some open source products with a ruge use base: MySQL (Alternative: MariaDB), OpenOffice (Alternative: LibreOffice), Hudson (Alternative: Jenkins) and Glassfish (Alternatives: TomEE/JBoss/Wildfly). Oracle had them all, Oracle lost them all.
Oracle keep insisting that Glassfish is not dead. The thing is: who decides whether Glassfish is dead or not is the community around it, not Oracle. If the community feels that the software is not reliable enough to be used in a real world environment then they won’t support it anymore. When there is no commercial interest in an open source product it means there is no sense of urgency to solve its bugs anymore. Some of those bugs may stay active for a long time. Since nobody can permanently live with bugs then the natural move is to abandone that technology and migrate to another one. At least, that’s what we are thinking about right now.
If we were lazy or afraid of changes, we would certainly move to WebLogic, but we are not. Our wish for freedom through open source is more important, even if it means a good deal of adaptations to another application server. We actually see it as a learning opportunity. We want to see the code. We want to see where the bug is and show it to the technical support. If we are clever enough, we could simply fix it and send the fix back to the community. None of this can be done with WebLogic.
We were happy Glassfish users and contributors. It gave us the feeling of being there first. We’re still using it to run instances of Yougi out there. We contribute to many other open source projects that use Glassfish as a JavaEE server. We use it in our daily jobs. We have reported several bugs, tested Glassfish 4 like crazy to use it one day. We were excited to heavily promote Glassfish in our community thanks to its fast move towards the latest specification. Now, we don’t find any motivation to keep doing what we were used to do. This is bad for the entire JavaEE community because they were used to contribute to a product that people would actually use after a while. Now, they have to find some other place to put their valuable code. It happens just now that the programme AdoptaJSR is attracting so many contributors.
Now we have to find an alternative and it is not that hard. We believe the natural move from Glassfish is towards TomEE/JBoss/Wildfly. No, we don’t care whether WebLogic can understand Glassfish deployment descriptors or they share some libraries or the basic support is cheaper. These are not good criteria because they are short term ones. When doing such a move we have to look beyond, long term, years ahead. We also have to take into account the risk of disappointment, frustrations and slowness towards the latest specification. We have to measure how close we are from the engineers who actually change the code base.
By the way, that’s the biggest advantage of the JavaEE specification. When we get upset with a supplier we can simply move to another one and keep 99% of the code unchanged. JCP rocks in that sense!!! That’s something you can’t do with Spring or .Net. If Pivotal (that already took the unstable role of Spring Source) or Microsoft fail or you get upset with them, you have no alternative, but rewrite your entire application to survive in the long run. We hope they never fail but shit happens sometimes :-/