Jakarta 2025 FAQ

Liferay DXP is evolving! To continue providing you with the most advanced and secure platform, Liferay is transitioning its underlying enterprise platform from Java EE 8 to Jakarta EE. This move, expected with our 2025.Q3 release, allows Liferay DXP to leverage the latest application servers and unlock enhanced performance, cloud capabilities, and robust security features.

While this is an exciting step forward, we understand you may have questions about what this means for your Liferay DXP deployment, especially regarding custom code and application server compatibility. This FAQ aims to address your most pressing business and technical inquiries to help you prepare for a smooth transition to Jakarta EE. Please note that this document will be updated periodically with new questions and information as the transition progresses.

Business Questions

Q: We are a Liferay SaaS customer; should we be concerned about Liferay’s migration to Jakarta EE?

A: Because Liferay manages all aspects of the underlying DXP platform, Liferay SaaS customers generally are not impacted by the Java EE to Jakarta EE migration to the same extent as Liferay PaaS or Liferay Self-Hosted (SH) customers.

However, as with any large migration or upgrade, Liferay SaaS customers should budget additional time for QA activities when their instance is upgraded to a Jakarta EE-based release.

Q: We don’t think we are using Java EE in our custom code, so we should not be impacted by the Java EE to Jakarta EE migration, right?

A: No, this is not correct. Because Liferay DXP itself makes extensive use of Java EE packages and frameworks, all Liferay DXP customers are impacted to some degree and should be encouraged to make plans for their eventual upgrade to a Jakarta EE-based release. Additionally, any Liferay PaaS or Liferay SH customer most likely have OSGi modules or Java EE portlets or servlets that must be migrated.

Q: Will it be possible for customers to purchase Extended Premium Support (EPS) on the 2025.Q3 release?

A: No, there are no exceptions to Liferay LTS and EPS policies. This is why we are encouraging customers to wait until the 2026.Q1 release before upgrading to a Jakarta EE-based release. Customers that cannot wait must make plans for an additional upgrade to an LTS version of Liferay once it becomes available.

Q: For those who are not technical, how big of an effort is this for customers? How does this migration compare to Liferay’s previous migration to OSGi?

A: The actual level of effort varies based on the amount of custom code involved and the use of third-party dependencies that may have their own migration paths from Java EE to Jakarta EE.

To help us gain a better sense of the level of effort and complexity, we are performing several migrations of internal systems currently so that we can get a better understanding of what the process looks like for our customers.

Technical Questions

Q: Will there be Jakarta EE compatible versions of portlet-specific Java EE frameworks such as Spring MVC or JSF available to use when doing traditional development for Liferay DXP?

A: Yes; new versions of Liferay Faces (JSF) and PortletMVC4Spring (Spring MVC) are planned for this year to support the Jakarta EE framework. PortletMVC4Spring (Spring MVC) is planned for release as part of the 2025.Q3 release, with Liferay Faces (JSF) to follow later this year. Developers working with 2025.Q3 and later must use the Jakarta EE framework.

Q: It was previously announced (and our documentation states) that JSF was deprecated due to the Jakarta migration. Can you provide more details on this?

A: We have changed our position on this, and we are no longer deprecating JSF support. The documentation has been updated to reflect this.

Q: For Liferay PaaS, will the container’s Java version be upgraded automatically, or must we configure this ourselves?

A: The Liferay Docker containers are already on Java 21 (no option for Java 17). With the 2025.Q3 release and later, they are moved to Tomcat 10 (Jakarta EE), since that is the only option in the container. Liferay PaaS users must still upgrade to new DXP releases and adjust any customizations.

Q: Do you have more details on the migration tools?

A: We are providing a new Blade/Liferay Workspace command with the following features:

• It will assist the replacement of javax with jakarta in custom code.
• It will also assist conversion of portlets to Portlet 4.0.

These tools are robust enough not only to search and replace javax with jakarta, but also to handle completely different naming patterns in the Jakarta EE version of the package.

They also cover common third-party libraries used in Liferay, and more importantly, apply all the necessary fixes needed for Portlet 4.0-—-beyond the scope of generic tools.

There are some things that it doesn’t support-—-specifically Faces or Spring Portlet conversion.

Q: How will references to Java EE in the Liferay database be handled?

A: The Liferay database is upgraded when moving to a Jakarta EE-based version of Liferay. The same database upgrade process you’ve used is enhanced to change javax references to jakarta automatically in known database tables.

For example, FreeMarker templates could contain javax references, so the database upgrade has been enhanced to update these tables and replace javax with jakarta.

A Liferay database can include custom tables created by customers, so it’s important for customers to understand their custom tables and the data they contain must be a factor in their upgrade planning.

Q: We have a customer that is waiting for a feature that is available in the 2025.Q2 release. It seems like we are discouraging customers from moving to this version; can they still upgrade to this release?

A: Yes; while we recommend customers avoid the 2025.Q2 release, if they need a feature in that release and cannot wait for the Q3 release, they can use the 2025.Q2 release in production. However, it’s important to understand that the 2025.Q3 release and beyond moves to the Jakarta EE framework, so the customer’s service period is shorter before they must upgrade to a newer release, and they must still do all the work to update their codebase from Java EE to Jakarta EE at that time.

Q: Is Liferay going to run the Jakarta EE upgrade process on their own systems?

A: Yes, we plan to upgrade several internal systems to the Jakarta EE release as soon as it is available. We will use these upgrades to identify issues and bugs, verify checklists and guides, and to formulate best practices.

Q: We have used Spring Boot to build Microservices Client Extensions. Must we migrate this code to Jakarta EE if we upgrade to 2025.Q3 or later?

A: No; the changes in DXP only affect code running in Liferay’s JVM. Microservice Client Extensions (and Liferay Workspaces) do not run in Liferay’s JVM and so are not impacted by this change. Depending on the version of Spring Boot being used, you might already be using Jakarta EE in your client extensions.

Q: Will there be any changes to the supported databases?

A: The Jakarta EE migration only impacts code running in Liferay’s JVM. Database support is not impacted.

Q: Will you also be updating the dependency versions to the latest version (e.g., jakarta.mail 2.x vs 1.6)?

A: All third-party libraries used by Liferay are updated to be Jakarta EE compatible. In some cases, we have upgraded to a Jakarta EE compatible version; in other cases, we have patched existing libraries to use Jakarta EE. The decision is based on several factors, including the features provided and overall compatibility with Liferay DXP, and may not always be the latest version available.

Q: My custom code is primarily using JAX-WS to produce APIs. How much will that be affected by the Jakarta EE migration?

A: It’s hard to quantify the level of effort required to migrate different codebases without fully analyzing the source code and dependencies. However, if your custom code uses libraries that are also used by Liferay, there is a much higher chance that the Liferay-provided migration tool can help you with the majority of the migration effort. The new Jakarta EE version of these specific libraries is required. The changes include package renames and individual classes, as well as some minor API changes. Please consult the public documentation for these libraries.

Liferay’s own REST Builder tool is updated to generate fully Jakarta EE-compatible APIs.

Q: As part of the migration to Jakarta EE, will Liferay be changing Java constants as well? For example, will JAVAX_PORTLET_REQUEST be updated to JAKARTA_PORTLET_REQUEST?

A: Yes, as part of the migration, we are updating all references to javax, not just the import statements and Gradle dependencies.