GlassFish 6.1 Should Not Be Used In Production: Here’s Why

Earlier this week, Jakarta EE 9.1 was released. This is an update to Jakarta EE 9, adding support for JDK 11 - you can read more about it in our bloghere.

Alongside the Jakarta EE 9.1 release, GlassFish 6.1 has been released as a Compatible Implementation. 

However, although GlassFish is still used by many - a legacy of the time it was supported by Oracle - we would argue it is NOT a good choice for running your enterprise applications in production.

If you are considering updating to more recent GlassFish versions, it might be better to consider more reliable, supported, and up-to-date alternatives. In this blog, I explain why GlassFish 6.x is not the best choice for your mission critical deployments.

Firstly, GlassFish 6.x uses theJakarta namespace which means you have to adapt your application to this namespace before you can run it on JDK 11. But there are many more reasons to consider other options...

GlassFish users: You might think you need to migrate your Java EE application to the Jakarta namespace in order to run on JDK 11. With Payara Platform, you can use all the same specifications with JDK 11, without needing to switch to the new namespace - and have been able to do so for two years!

Unlike with GlassFish, Payara Platform gives you freedom over how and when you move to the new jakarta namespace. With Payara Platform 5, we use Eclipse Transformer tools so that you can move to the Jakarta namespace incrementally ... or not at all, it's up to you.

Lack of Maintenance and Framework Updates 

Every specification must have been tested before it is released in order to prove that it is possible to implement it. Otherwise, a specification could have some impossible requirements.

The Jakarta EE specification contains several optional parts, so it must be tested on a runtime that implements all these optional elements.  GlassFish is, alongside the Payara Platform,  the only Jakarta EE runtime that implements all the optional specifications. Since GlassFish is also a truly vendor-neutral product, it is at this current time used as the testing implementation of the Jakarta EE specification, and therefore it's used to verify the usability of each new release. 

This is why GlassFish continues to be updated despite not being tied to a specific vendor or project team. However, although the GlassFish server is being updated, it is not maintained like other runtimes or given the necessary continuing attention between Jakarta EE releases.

There is always only one release with each new Jakarta EE iteration, just to pass all the tests of the TCK (Technology Compatibility Kit) suite of the Jakarta EE specifications. This means that, when there are newer versions of EclipseLink, Mojarra, or any other framework are released, they are not updated within GlassFish.

This is in contrast with the Payara Platform, where we update the frameworks regularly so that fixes from libraries like EclipseLink and Mojarra are included.

Lack of Support 

Since each new GlassFish release is only created to verify the Jakarta EE specifications, there is also no company behind GlassFish supporting you and your team.  It may be possible to obtain third-party support services, but this is not the same as having a fully supported application server, with support provided by the same team that works on development.

GlassFish has a long list of known bugs but they are not addressed by anyone. It is an open source project, so anyone can provide a fix for them voluntarily,  but there is no project team to include them into the code base and provide another release.

A better option for companies are runtimes like Payara that are actively supported. We have already addressed all the known bugs of GlassFish. We also work together with all our customers to address problems and provide them with a fix for any issue that may arise.

Lack of Modern Security Fixes and Standards

Alongside the fact that there is no support for solving bugs, security vulnerabilities are also not addressed. For bugs, there is a workaround most of the time so you can still use GlassFish and run your application. In contrast, security vulnerabilities that are not fixed leave your environment at risk. This could lead to data breaches and, potentially, a huge negative impact on your business.

It is therefore hugely important to choose a runtime that has very frequent updates; where  vulnerabilities and bugs are addressed rapidly. Payara Platform has regular releases to ensure your applications run in the best possible environment; monthly releases are guaranteed for Payara Enterprise, our application platform for mission critical systems in production. 

No Cloud-Related Support or Hollow Jar Functionality 

Since GlassFish has only been updated in the last 5 years to allow the Java Enterprise specification, Jakarta EE to pass, there are no new features and functionalities implemented.  This means GlassFish has remained static, failing to evolve in tandem with the IT industry as a whole, where there has been a clear and significant move towards cloud technologies. 

You can create a Dockercontainer based on the GlassFish executables, of course, but it will just use the same principles of an on-premise setup but in a Container. GlassFish still uses the new abandoned project Shoal for clustering, for example, while Payara switched toHazelcast, allowing us to have an automatic and flexible clustering in a cloud environment.

Since there was no cloud-related functionality developed within GlassFish, typical concepts like Kubernetes Secrets can't be used and a more flexible deployment option like Hollow Jar is not available. With the Hollow Jar option, you can remove the need for separate installation of configuration steps of your environment and just launch an executable Jar, likePayara Micro, which supports the Jakarta EE Web profile.

No Microservices Support

Many resources mention that it is perfectly possible to write microservices with Java EE and Jakarta EE, especially when you combine them with the MicroProfile Specifications. These specifications are maintained by a global open source community, the Eclipse Foundation.

MicroProfile is designed to make it easier to create applications following the 12-factor app paradigm and help you with the observability challenges in a microservice architecture. If you are using GlassFish, you are missing out on the benefits of MicroProfile. 

With MicroProfile config, your application configuration values can be easily maintained outside of the application and adapted to the environment the application is running in. The Request Tracing specification makes it possible to trace a single user request through the different services to create the response for the end-user. It helps you in debugging and profiling requests.

Payara Platform products have an implementation of the latest MicroProfile specifications and make it easier to create microservices and connect with typical cloud native products like etcd, Prometheus, and Jaeger.

Summary

With the release of GlassFish 6.1 and its ability to run on JDK 11, a lot of companies may decide to delay the decision to move from GlassFish, despite realising that it is not a good solution to run a Jakarta EE application in production.

These companies will need to change their application to the new namespace; it is not a maintained runtime as it is assembled only for the purpose of testing the Java Enterprise specification, and there are no bug and vulnerability fixes as there is no support or designated product team.

On top of this, in the last five years, the IT world has changed significantly, with many applications moving to cloud environments. GlassFish hasn't been able to evolve in line with this change and is therefore an inferior solution for cloud deployments. 

So, whilst this recent iteration of GlassFish might seem like a tempting reason to stay with the technology, it will ultimately remain outdated. Don't get lulled into a false sense of security by the new release, and instead look at more secure and reliable alternatives for your applications in production. 

I've begun to discuss why Payara Platform presents a better option, but you can investigate our resources to understand this in more detail and find out how you can begin to migrate: