Here’s the thing: Liferay’s moving the needle hard on its Java stack. If you’re running Liferay DXP or planning upgrades, you need to be on top of this. Let’s break down what’s happening and why it matters with precision and purpose. 

The Shift: Why Liferay Is Moving from Java EE to Jakarta EE and Embracing Java 21 

Liferay is transitioning from the legacy Java EE (javax.) to Jakarta EE (jakarta.), aligning with Jakarta EE 10 starting in 2025.Q3. Meanwhile, Java 21 is emerging as the preferred runtime. Liferay strongly recommends JDK 21, though they’ll still compile on Java 17 temporarily. 

What this means for you: 

• Improved security, performance, and vendor support.

• Access to modern app servers (Tomcat 10.1, WildFly 26/30, JBoss EAP 8, etc.). 

• Future-proofing your platform, especially if you rely on third-party integrations or custom modules.

Transition Roadmap: What Leaders Should Know 

Here’s where things line up: 

The Migration: javax.* → Jakarta.* 

Custom code using Java EE APIs needs a namespace overhaul. Liferay provides tools (Blade CLI and Workspace) with a source-formatter that handles search-and-replace and migration for many artifacts. 

Key nuances: 

• Database references (templates, FreeMarker, custom tables) get auto-updated during upgrade.

• Not all cases are covered, facelets (JSF) or Spring portlet modules may need manual tweaks.

• Toolchain changes are sweeping (Blade CLI, Gradle plugins, REST builder) updated for Jakarta.

Planning for Success: A Business-Outcome Approach 

Here’s how to get ahead: 

1. Assess now: Use migration assessment tools or work with partners like Nirvana Lab to map custom dependencies and workloads.

2. Create a migration project plan:

• Branch your codebase early.

• Run formatter tools in controlled passes (Jakarta transform first, then upgrade) Liferay.

• Exclude sensitive directories (bundles, configs) from automated tooling.

3. Staged upgrades:

• Start with sandbox or PaaS environments.

• Reserve SaaS for later, Liferay handles most of that journey.

4. Update CI/CD pipelines:

• Ensure builds use the correct Workspace plugin versions.

• Lock versions to avoid the auto-updating toolchain unexpectedly.

5. Test deeply:

• Cover templates, APIs, portlet behavior, REST endpoints.

• Watch for subtle API changes or signature shifts.

6. Educate devs and Ops:

• Train on new tools, Jakarta EE APIs, and potential pitfalls (e.g., taglibs, TLDs, JSP issues).

7. Coordinate timing:

• Align migration with planned maintenance windows.

• Avoid moving to 2025.Q2 unless you have a compelling reason, the transition effort compresses later.

Why It’s Worth It: Outcomes That Matter 

• Longer shelf life: Moving to Jakarta EE and Java 21 ensures your platform stays supported and secure well beyond 2028.

• Performance gains: Java 21 offers real improvements in memory footprint, performance, and cloud cost savings.

• App server modernization: You can adopt better, more secure servers like Tomcat 10.1 or JBoss EAP 8.0.

• Better support: Most vendors now support Jakarta EE, avoiding being stuck on dwindling Java EE tools.

• Team agility: Once migrated, your devs can use modern Java features and cleaner APIs, boosting velocity and maintainability. 

Final Word 

Liferay transition to Jakarta EE with Java 21 isn’t a minor version bump, it’s a deliberate modernization. Yes, the namespace shift, tooling overhaul, and custom-code refactoring are real work. But having a plan, splitting the project into digestible phases, and aligning with Liferay’s roadmap gives you stability and optionality. 

Here’s what to do next: Start baseline assessments now. Branch your code. Build a migration timeline tied to quarterly releases. Equip your teams. And remember, this isn’t about buzzwords. It’s about keeping your digital experience platform safe, fast, and future-ready. 

Frequently Asked Questions