JSF/Jakarta Release History

How Does Jakarta Faces Version Support Actually Work?

Jakarta Faces is a specification, not a standalone product -- which means it does not have its own independent EOL dates. Support is tied directly to the Jakarta EE platform release that ships it. Each Jakarta EE platform release targets a specific Faces version, and when a platform version ages out, so does the Faces version bundled with it. The specification itself is maintained by the Eclipse Foundation under the Jakarta EE Working Group.

Jakarta EE follows a roughly two-year release cadence. Each platform release supersedes the previous one as the actively developed version. There is no formal LTS designation within Jakarta EE itself -- the "supported" version is whichever Jakarta EE release your application server vendor is currently maintaining. That vendor relationship is where real-world support timelines come from.

Specification vs. Implementation

In practice, you run an implementation of the Faces spec, not the spec itself. The two major implementations are Eclipse Mojarra (the reference implementation, used in GlassFish and Payara) and Apache MyFaces (used in TomEE and WildFly/JBoss EAP). Each implementation has its own release cadence and support policy, and each is bundled differently depending on your application server. For Mojarra 2.3 and earlier, the Mojarra project explicitly directs users to their application server vendor for support. Details on current specification versions are available at jakarta.ee/specifications/faces.

What Breaks When You Run an Outdated Faces Version?

Running an old Jakarta Faces version in a modern Java environment creates dependency chain problems that are harder to debug than a simple version mismatch. Faces integrates deeply with CDI, the Servlet API, Expression Language, and Bean Validation -- all of which also evolve with each Jakarta EE release. An outdated Faces version may be incompatible with a newer version of any of these dependencies, causing subtle runtime failures rather than clean startup errors.

The javax-to-jakarta namespace migration (Faces 3.0) is the most disruptive example of this. Code compiled against javax.faces.* simply cannot be loaded in a container that only provides jakarta.faces.*, and vice versa. There is no transparent bridge -- applications and component libraries all need to be on the same side of that divide. Teams still running Faces 2.x on a modern Jakarta EE 10+ server will find that nothing resolves correctly at the class loader level.

What Happens After a Faces Version Falls Out of the Current Jakarta EE Release?

When Jakarta EE moves to a new platform release, the previous Faces spec version does not receive further development from the Eclipse Foundation. Bug reports and feature requests are directed to the new version. The specification document for the old version remains published and accessible -- the spec does not disappear -- but no new TCK tests are written and no errata are issued.

For the implementations, behavior differs by project. The Mojarra project on GitHub currently focuses on the current spec version; for Mojarra 2.3 and earlier, the README explicitly states that support comes from your application server vendor -- Red Hat, IBM, Oracle, Payara, and others -- rather than from the upstream project directly. Apache MyFaces follows a similar pattern, with older spec versions maintained primarily through community contributions rather than active development.

In practice, this means your real support window is determined by your application server vendor. Red Hat JBoss EAP, IBM Liberty, and Payara Enterprise each publish their own lifecycle policies with specific dates for Jakarta EE version support. Teams running Faces 2.3 on a JBoss EAP 7.x subscription, for example, are still covered -- until JBoss EAP 7 itself reaches end of support under Red Hat's terms. Once that vendor support ends, you are on your own regardless of what the upstream spec says.

How To Check Your Jakarta Faces Version

The Faces version in use at runtime can be read directly from the implementation JAR's manifest or via the API itself. The simplest approach from a Facelets view:

<!-- In any .xhtml page -->
#{facesContext.externalContext.applicationMap['jakarta.faces.version']}

From Java code, query the implementation version directly:

import jakarta.faces.context.FacesContext;

String version = FacesContext.class.getPackage().getImplementationVersion();
System.out.println("Faces impl version: " + version);

On the server side, check the JAR manifest of your implementation. For Mojarra:

unzip -p /path/to/jakarta.faces.jar META-INF/MANIFEST.MF | grep -i version

You can also check the version declared in your pom.xml or build.gradle against the current release listed in the release table above. The current spec versions are listed at jakarta.ee/specifications/faces.