Versions & Implementations

Jakarta Faces is a specification: a document, an API, a tag library description and a technology compatibility kit (TCK) published by the Eclipse Foundation under the Jakarta EE Specification Process. The 4.1 specification page links the specification document, the Javadoc, the JavaScript documentation, the render kit documentation, the tag documentation (VDLDoc) and the TCK, and lists the Maven coordinates jakarta.faces:jakarta.faces-api as the API artifact. An implementation is a separate product that passes the TCK and is then listed as a compatible implementation. Two implementations are in production use:

The practical consequences are these. Application code compiles against the API only, so the dependency on jakarta.faces-api has scope provided when the server brings its own implementation. A server that does not (Tomcat, a plain Servlet container, an embedded runtime) needs an implementation in the WAR. Anything implementation specific — context parameters in the com.sun.faces or org.apache.myfaces namespace, internal classes, default values that the specification leaves open — is a portability risk and is covered in the next section.

The Maven snippets below show the three ways to put Faces on the class path of the Bookshelf WAR. The first is for a Jakarta EE server: nothing is packaged. The other two package an implementation. The Mojarra artifact org.glassfish:jakarta.faces already contains the API classes, so with Mojarra the provided API dependency is only needed to compile against a specific API version when the server supplies the runtime; the MyFaces implementation artifact pulls its API artifact myfaces-api in transitively, and the API comes from MyFaces itself rather than from jakarta.faces-api. All three variants were built with mvn package in the scratch project.

A real project uses one of the three blocks, not all of them. Variant B is the one the Tomcat and Weld page of this section builds on, and variant C appears again on the Spring Boot with JoinFaces and Quarkus pages, where MyFaces is a common choice. The jakartaee-web-api artifact (the Web Profile) is enough for a Faces application; the full jakarta.jakartaee-api is only needed if the code also uses Platform-only specifications.

Source: Jakarta Faces 4.1 specification page and Apache MyFaces Core 4.1

Both implementations pass the Faces TCK, so a portable application behaves the same on either. The differences are in what surrounds the specification.

MyFaces 4.0 is a new code base. The MyFaces 4.0 page says that it is based on the 2.3-next branch and is a completely new code base compared with 3.0 and 2.3: shared modules and dependencies were removed, the size is about 1 MB smaller, it has no dependencies, it is said to be up to 15% faster when the lambda meta factory is enabled, the JavaScript was rewritten in TypeScript and the default parameters were tuned for usability and performance.

Release cadence. Counting the versions published on Maven Central, Mojarra published seventeen 4.1 releases (4.1.1 on 2024-06-25 up to 4.1.17 on 2026-09-18) and patched the 4.0 line to 4.0.26 in the same period, which is roughly one release every seven weeks. MyFaces published five 4.1 releases (4.1.0 on 2024-12-04 up to 4.1.4 in September 2026), a slower rhythm. Both lines receive fixes after a new minor version appears, so staying on the latest patch of the line you use is the normal upgrade path. Faces 4.1 itself was ratified on 2024-06-04, six months before MyFaces 4.1.0; the specification page lists Mojarra 4.1.1 and the two GlassFish 8 milestones as the implementations that certified it.

Context parameters. Parameters whose names start with jakarta.faces. are defined by the specification and are read by both implementations; examples are jakarta.faces.PROJECT_STAGE, jakarta.faces.FACELETS_REFRESH_PERIOD, jakarta.faces.STATE_SAVING_METHOD and jakarta.faces.ENABLE_WEBSOCKET_ENDPOINT. Names that start with com.sun.faces. belong to Mojarra and names that start with org.apache.myfaces. belong to MyFaces. The defaults differ, which matters when an application moves from one to the other.

An implementation reads only its own parameters, so the example below configures the same intent for both. Replace the values with the numbers your own load test justifies; keeping fewer remembered views reduces the memory used by server state saving per session, at the price of the browser’s Back button failing earlier.

Source: Apache MyFaces Core 4.1 — configuration tables and Mojarra WebConfiguration (4.1 branch)

Telling the two apart at run time. A page or a log line that reports the implementation helps when a bug report must name it. The bean below decides from the package of the Application object and reads the API version from the manifest of the API jar; the view prints both.

Source: FacesContext (Jakarta Faces 4.1 API)

Jakarta EE is published as three specifications that list what a compatible product must provide: the Platform, the Web Profile (a subset aimed at web applications) and the Core Profile (a much smaller subset for microservice runtimes). Faces belongs to the first two.

The same relationship holds one release earlier: Jakarta EE 10 includes Jakarta Faces 4.0 in the Platform and in the Web Profile. For Jakarta EE 12 the Platform and Web Profile pages announce the update "Jakarta Faces 4.1 to 5.0" and a minimum of Java SE 21; that release is still being planned.

What this means for a project. If the target is "any Jakarta EE 11 Web Profile server", declare jakarta.jakartaee-web-api as provided and write only standard Faces. If the target is Tomcat or a Core Profile runtime, package an implementation as in variants B or C above, and remember that CDI, Expression Language and Bean Validation have to be present as well; the Tomcat and Weld page of this section does that. The Jakarta EE servers page covers the servers one by one.

Source: Jakarta EE Web Profile 11, Jakarta EE Platform 11, Jakarta EE Core Profile 11 and Jakarta EE Platform 12 (in development)

Each Faces release raised the minimum Java version together with its Jakarta EE release. The 4.0 and later values are printed on the specification pages as "Minimum Java SE Version"; for the older versions the table uses the requirements published by the implementations, because the specification pages of 2.x do not state one.

Two details are easy to get wrong. First, running on a newer JDK than the minimum is normal — the examples of this section use Java 21 and compile with JDK 26 — but the minimum decides which language features the API may use: Faces 4.1 requires Java 17, so records are fine in beans and jakarta.faces.view.ViewScoped beans may be written as classes that use List.of. Second, the application server may demand more than Faces: MyFaces 4.1 lists Servlet 6.1, EL 6.0 and CDI 4.1 as requirements, which is why it needs a Servlet container of the Tomcat 11 generation.

Source: Jakarta Faces 4.1 — minimum Java SE version, Jakarta Faces 4.0, Jakarta Faces 5.0 and the MyFaces 2.2 and 2.3 version pages

The matrix joins the specification line to the libraries and servers around it. The Faces, Jakarta EE and Java columns come from the specification pages. The implementation columns give the last line of each project as published on Maven Central. The server column lists the products that the Jakarta EE site shows as certified for that release.

PrimeFaces. One jar serves several Faces versions. PrimeFaces 16.0.0 (2026-09-04) is documented as requiring a Java 11 or later runtime and a Faces implementation, and its Maven download page offers the single artifact org.primefaces:primefaces for "Jakarta Faces (4.0 - 5.0, jakarta namespace)". The 15.x line (15.0.18) is the previous one. The PrimeFaces dependency page still lists older Faces versions in a table, so treat the download page as the statement for the jakarta line. PrimeFaces Extensions has a matching 16.0.0.

Servers. The Jakarta EE site lists, for the Jakarta EE 11 Platform, Eclipse GlassFish 8.0.0-M12, Azul Payara 7.0.0 and Payara Community 7.2026.5, and Open Liberty 26.0.0.5; for the Web Profile, GlassFish, Payara and Open Liberty; and for the Core Profile, WildFly 34 and Open Liberty. The WildFly project announced that its 40 release delivers Jakarta EE 11 support. Apache TomEE 10.2.0 implements Jakarta EE 10 and the TomEE 11 download is a 11.0.0-M1 milestone for Jakarta EE 11. Tomcat is a Servlet container and not a Jakarta EE product: Faces on Tomcat means packaging an implementation, CDI (Weld) and Expression Language, as in variants B and C above. At the time of writing the current GlassFish is 8.0.5, WildFly 41.0.1.Final, Payara 7.2026.9 and Open Liberty 26.0.0.10 with the faces-4.1 feature; the certification lists above name earlier builds because they are the ones submitted for certification.

Source: Jakarta EE compatible products, Jakarta EE 11 certification results, Jakarta EE 10 certification results, OmniFaces versions and PrimeFaces 16 — Download

The appendix "Change Log" of the specification lists every issue per release, back to 2.0. The summaries below keep what matters to a Bookshelf developer. Each version has one short example, written with current names, for a feature that first appeared in that version.

See also Java, Web UI frameworks for Spring Boot and Starting a new project when the version decision is part of a wider technology choice, and Vaadin and Thymeleaf for the alternatives covered on this site.

All eight books consulted for this section date from 2004 to 2015 and describe JSF 1.0 to 2.2 (and PrimeFaces 4 and 5). On versions and implementations they are outdated in these ways, and the official documentation wins in every case.