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:
| Quarter / Period | What’s Changing | Impact on Your Team |
|---|---|---|
| 2025.Q1 | LTS version on Java EE (javax), support until Feb 2028 | Safe ground, but nearing obsolescence |
| 2025.Q2 | Jakarta EE preview, deprecated JDK 17 | Possible feature gaps, risky to skip planning |
| 2025.Q3 | Full Jakarta EE 10, mandatory namespace shift, app server upgrades, recommended JDK 21 runtime | Major lift, custom code must migrate |
| 2026.Q1 (LTS) | Jakarta EE baseline with long-term support, Java 21 compile+runtime | Ideal target for stability post-migration |
| 2026+ | Full switch to Java 21, Java 17 deprecated | End of mixed-version maintenance |
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:
Key nuances:
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
Why is Liferay moving from Java EE (javax) to Jakarta EE (jakarta)?
Because the Java EE namespace is retired. Jakarta EE ensures future support, compatibility with modern servers, and access to the latest Java features.
Do I need to upgrade to Java 21 immediately?
Not mandatory right away, but highly recommended. Java 21 is the long-term supported runtime that Liferay will align with post-2025.
What happens if I keep using javax APIs?
Your code will break on Jakarta-based versions. You must migrate to the jakarta namespace to stay compatible.
How can I migrate my custom Liferay modules?
Use Liferay Workspace tools and Blade CLI’s Jakarta transformation. Some complex cases (like JSF or Spring portlets) may need manual fixes.
What’s the business upside of migrating now?
Lower risk, stronger security, smoother performance on Java 21, and a longer supported lifecycle for your DXP platform.
