Jakarta EE’s Next Chapter
At OCX 2026, Eclipse Foundation leaders Ivar Grimstad and Tanja Obradovic laid out a clear message: Jakarta EE is not trying to reinvent enterprise Java. It is trying to modernize it without breaking what made it valuable in the first place. Their sessions walked through the evolution from J2EE complexity to today’s lighter, profile-based Jakarta EE model, while also addressing a harder question: how does a mature standards platform stay relevant in an era shaped by AI tooling, faster release cycles, and changing developer expectations?
The Bigger Picture
A Governance Model Built for Longevity
Jakarta EE’s transition from Oracle’s stewardship to the Eclipse Foundation was framed as more than a branding exercise. It was a structural reset driven by community demand for open governance, faster progress, and broader participation. Oracle retained Java SE, while the enterprise specification layer moved into a neutral foundation model. This is a relevant shift as Jakarta EE’s long-term value has always been bigger than any single API.
Its real strength is interoperability. A developer building enterprise software at one global organization can understand and work with software built by another because both rely on common specifications for persistence, transactions, security, and web services. That consistency lowers switching costs, reduces lock-in risk, and creates a deeper labor pool for enterprise buyers. Obradovic emphasized that this shared standard model was a major reason Enterprise Java became so widely adopted in the first place.
That still matters today. As organizations rethink platform concentration risk and software procurement flexibility, open specifications remain strategically relevant.
What This Means for ITDMs
For IT decision-makers, the Jakarta roadmap offers a practical modernization path rather than a disruptive rewrite mandate.
A recurring point during the OCX sessions was that many enterprises continue to run older Java versions because large systems are stable, reliable, and expensive to change. But that caution can create hidden debt. Performance improvements, security fixes, and operational efficiencies increasingly come from staying current with the Java runtime. Grimstad was direct: in many cases, upgrading Java versions alone can improve application performance without changing application code. That is a compelling ROI case for IT leaders managing aging estates.
Licensing economics also remain part of the equation. Large organizations using Oracle Java with commercial support often face non-trivial cost decisions around LTS upgrades. In that context, OpenJDK alternatives and migration tooling such as Eclipse Transformer become strategically useful because they can reduce friction during transitions.
Compatibility assurance is another differentiator. Jakarta EE’s TCK-backed certification model means vendors cannot simply claim support. They must pass compatibility tests, and at least one implementation must be open source before a specification is finalized. For procurement teams, that provides stronger verification than many proprietary platform claims.
What This Means for Developers
Jakarta EE 11 and the planned Jakarta EE 12 release reflect a platform focused on practical developer experience rather than flashy repositioning. Jakarta EE 11 introduced Jakarta Data and expanded modernization work around concurrency and CDI-centric programming. Jakarta Data brings a repository model familiar to Spring developers while adding inline query support through annotations. That lowers adoption friction for developers moving across ecosystems while preserving standards-based portability.
The virtual threads example presented at OCX highlighted Jakarta’s conservative but useful design philosophy. Rather than forcing API rewrites, the platform adds runtime-aware support so the same binary can benefit from newer Java capabilities when available. That kind of incremental modernization is often more valuable in enterprises than greenfield novelty.
Jakarta EE 12 is expected to continue that trajectory with broader CDI alignment, query improvements, possible NoSQL additions, and continued support for both lightweight and full-platform deployments. Speakers repeatedly stressed flexibility: developers should be able to use a single specification, a microservice-oriented subset, or the full platform depending on need.
That message matters, especially when many developers still associate Jakarta with older “big app server” assumptions that no longer reflect the current model.
AI Strategy: Standardize the Integration, Not the Model
The Eclipse Foundation’s AI position was one of the more thoughtful themes from OCX. Jakarta EE is not trying to compete with Python ecosystems or build foundation models. Its focus is on defining standard ways for enterprise Java applications to connect with AI services, models, and agents. That distinction is important.
ECI Research’s 2025 AI Builder Summit found that two-thirds of enterprise AI leaders have already implemented multi-agent collaboration in live or pilot workflows. But the same research found that 44% have only moderate confidence that AI agents can operate autonomously without human intervention. That gap between experimentation and trust is where standards can matter most.
Jakarta’s emerging AI and agentic specifications appear designed for exactly that layer: secure invocation, governed orchestration, and portable integration patterns rather than model ownership. That aligns with another ECI Research finding: 70.9% of organizations source agentic AI capabilities through platform vendors rather than building everything internally. In that market, vendor-neutral integration standards could become increasingly valuable.
Looking Ahead
Version Cadence and the LTS Alignment Strategy
Jakarta EE’s established rhythm of releasing roughly one year after Java LTS versions remains sensible for core platform stability. But speakers openly acknowledged that AI-related capabilities may need to move faster than the traditional cadence.
That creates a dual-speed challenge familiar to many enterprise platforms: maintain compatibility where stability matters most, while accelerating innovation where markets are changing fastest. If Eclipse can sustain that balance, Jakarta stays relevant.
The Next Developer Generation Is the Real Long-Term Risk
Perhaps the most candid point at OCX was that relevance is not only about features. It is about future developers.
Obradovic discussed hackathons, university outreach, Java User Groups, mentorship programs, and direct community engagement as core priorities instead of side projects. That makes sense when considering that Jakarta EE has a massive installed base, but long-term platform health depends on whether new developers see it as an option rather than legacy infrastructure.
Ironically, the namespace migration from JavaX to Jakarta helped raise awareness. Painful as it was, it reminded nearly every Java developer how much enterprise software still depends on these specifications.
Jakarta EE is not chasing hype. It is doing something harder: updating enterprise foundations while preserving trust, portability, and compatibility. That may not generate the loudest headlines, but for organizations running mission-critical systems, and for developers who need software to keep working while everything else changes, it remains a very relevant strategy.
SAP and S3NS Bring Sovereign Cloud ERP to France
OCX 2026 Wrap-Up: Open Source Finds Its Moment in the Heart of Europe
Eclipse ThreadX and RISC-V Advance the Open Embedded Stack
CRA Compliance and Trustable Software: What OCX 2026 Revealed
Jakarta EE AI Integration: What’s Coming in EE 12 and 13
