Eclipse GlassFish: Swimming Towards Jakarta EE 10

The Eclipse GlassFish application server is a compatible product for every Jakarta EE release, and it has very deep roots in the Java world. The GlassFish technology can be directly traced back to the Sun ONE Application Server 7 (S1AS 7), which was Sun Microsystem’s primary server product in 2003. Indirectly, GlassFish can be traced all the way back to the Kiva Enterprise Server from 1996.

Today, the GlassFish technology is flourishing at the Eclipse Foundation, and is being updated to strengthen its merits as an application server. 

From Reference Implementation to Compatible Implementation

GlassFish was the reference implementation for Java EE for many years. Among other things, that meant an update to a Java EE specification could not be officially released until GlassFish implemented it and passed the associated Technology Compatibility Kit (TCK) tests.

When GlassFish moved to the Eclipse Foundation and Java EE became Jakarta EE, the Eclipse Foundation Specification Process replaced the concept of a reference implementation with the concept of a compatible implementation. With the compatible implementation concept, any implementation can be used to ratify a new specification release. This change means Eclipse GlassFish no longer has special standing in the specification process or any special designation. It’s now a Jakarta EE implementation at the same level as all other implementations.

Adjusting the TCK for Jakarta EE 10

The Jakarta EE TCK has GlassFish dependencies in several places and includes many files that are specific to GlassFish, such as files that tell the TCK how to deploy test archives. For the Jakarta EE 10 version of the TCK, the team has been working incredibly hard to remove these dependencies, and has made considerable progress. 

Specifically, the dependency on GlassFish for building the TCK has been almost entirely removed. This was always a less-than-optimal dependency that was conceived out of convenience rather than any solid engineering principles. The dependency was removed by turning the TCK into a regular Maven project and referencing all of the various Jakarta EE APIs using their official Maven coordinates.

The work doesn’t stop there. GlassFish is currently supported out of the box, while other implementations need a porting kit. This porting kit provides resources such as the above-mentioned files to deploy test archives. It also provides implementations of various TCK interfaces that developers can include in their code. For example, the TCK allows developers to redefine a URL using a kind of factory. 

The full TCK also includes tests for communications between application servers, which means it supports the concept of a reference implementation and a vendor implementation. Both are started during test runs. Currently, GlassFish is always the reference implementation in the TCK. At some point, it should be possible to use any compatible implementation, or perhaps the entire concept of interoperability testing should be removed.

The work on the porting kit and reference implementation are ongoing, and may not be complete when Jakarta EE 10 is released.

Addressing the Optional Features Limitation

Jakarta EE includes a number of optional features that are specified, but don’t need to be implemented for a product to be deemed compatible with the specification. The Digest authentication mechanism in Jakarta Servlet is an example of such a feature.

However, there is an exception to this rule. The implementation that’s used to ratify the specification must implement all optional features.

This requirement puts a burden on the implementation because it cannot drop the feature if it’s not needed. It also puts implementations that don’t include optional features at a disadvantage because they can’t be used to ratify the specification.

In practice, this requirement means that even after removing the reference implementation concept, GlassFish is still one the few implementations that can be used to ratify specifications. The Jakarta EE 10 release plan recognizes the issue, and explicitly states, “The number of compatible implementations available for specification ratification is limited due to the requirement that all optional features need to be implemented and verified via the TCK.”

A solution to address this limitation is in progress, but again, it may not be completed in time for Jakarta EE 10.

GlassFish is Flourishing at the Eclipse Foundation 

Even though GlassFish is still tied to the reference implementation concept in practical terms, those days are clearly coming to an end. That means GlassFish must now stand on its own merit.

GlassFish certainly stood on its own merit when it was Sun’s primary server product. However, after Oracle acquired Sun, GlassFish was gradually positioned to focus more on its reference implementation role and less on its role as a server in its own right.

The last version of GlassFish released under Sun — the famous version 3.0 — was the last version to receive a major architectural update. Internally, the many references to “V3” confirm that. Even though GlassFish 4 did include a good number of bug fixes, the main goal was to update its components to the Java EE 7 specification versions. And GlassFish 5 essentially updated its components to the Java EE 8 specification versions.

After the transfer of GlassFish from Oracle to the Eclipse Foundation and migration to the jakarta.* namespace, the GlassFish team has been steadily increasing the number of bug fixes, security fixes, and architectural improvements included in the software (Figure 1). 

Figure 1: Commit Graph for Eclipse GlassFish

Eclipse GlassFish has also adopted a regular release cadence, with new releases approximately every month (Table 1).

Table 1: Recent Eclipse GlassFish Releases

 

In a major addition, Eclipse GlassFish incorporated Jakarta Model-View-Controller (MVC), which is an alternative MVC framework that is not yet in the full Jakarta EE platform. The GlassFish team also moved relatively quickly to support JDK 16 and JDK 17. Given the age of the GlassFish code base, and the fact that Sun could easily copy JDK code into GlassFish as the owner of both, this task was not trivial.

The GlassFish team has also started to extract some of the code into separate projects. This separation allows other implementations to easily reuse the GlassFish implementation of Jakarta EE specifications. For many specifications, such as Jakarta Server Faces, this has always been possible, but some specifications have not had standalone implementations. 

Eclipse Exousia is the first such project, implementing Jakarta Authorization. With Eclipse Exousia, developers can add Jakarta Authorization support to servers such as Tomcat. And newer servers, such as Piranha Cloud, can take advantage of Jakarta Authorization by simply integrating it.

GlassFish 7 and Jakarta EE 10

The main branch of the GlassFish project is expected to switch to GlassFish 7/Jakarta EE 10 soon after the release of GlassFish 6.2.3, which is scheduled for November 2021.

The first components planned for integration include:

• The newly named Eclipse Angus 1.0.0-M1 release, which implements Jakarta Activation 2.1 and Jakarta Mail 2.1
• Eclipse Mojarra 4.0-M2, which implements Jakarta Server Faces 4.0

There are also plans to update the Servlet container inside GlassFish to support the Jakarta Servlet 6.0-M1 API draft.

Get Involved in Eclipse GlassFish

For more information about Eclipse GlassFish and to get involved:

• Visit the Eclipse GlassFish website
• Subscribe to our mailing list
• Open a GitHub issue to provide feedback and comments