Vicedomini Softworks

Software Development

Jakarta EE 11: Cloud Native and AI for Italian Engineers

12 September 2026

Jakarta EE 11: Cloud Native and AI for Italian Engineers

Java enterprise today means Jakarta EE, the standards-based successor to Java EE now governed by the Eclipse Foundation. It is vendor-neutral, actively maintained through releases such as Jakarta EE 11, and compatible with modern runtimes and AI integration patterns. Spring Boot and Jakarta EE increasingly overlap rather than compete, since Spring Boot 3.x itself runs on Jakarta specifications.

TL;DR:

  • Jakarta EE supports multi-vendor compatibility and longer software longevity, as specifications evolve more slowly than individual implementations.
  • Spring Boot 3.x now runs on Jakarta specifications, meaning many teams already consume Jakarta EE APIs without realizing it, which affects deployment choices.
  • Jakarta EE 11 introduces Jakarta Data for reducing boilerplate and virtual threads for high concurrency, but runtime selection impacts performance, startup time, and resource use.
  • For cloud-native deployment, MicroProfile fills gaps in Jakarta EE with externalized configuration and health checks, with packaging options like native images or WARs influencing operational complexity.
  • Existing APIs and libraries enable current Jakarta EE applications to integrate AI and large language models without waiting for dedicated standards, while migration often faces runtime behavioral differences.
Vicedomini Softworks
Build Software That Scales
Vicedomini Softworks helps organizations modernize systems and build secure, scalable software with direct collaboration from experienced engineers.
Explore software engineering

Table of Contents

What is Jakarta EE and how does it relate to Java EE?

Oracle donated Java EE to the Eclipse Foundation in 2017, and the project was renamed Jakarta EE after a trademark dispute forced a namespace change from javax.* to jakarta.*. That single technical detail broke binary compatibility for older applications, but it also freed the platform from a single-vendor bottleneck. Governance now runs through open working group charters, with specifications proposed, debated, and ratified by a community of vendors and practitioners rather than one company’s roadmap.

Jakarta EE works on a specs versus implementations model. The specification defines an API contract; runtimes such as Payara, WildFly, or Open Liberty implement it, and applications written against the standard can, in principle, move between them.

This separation matters for three practical reasons:

  • Portability: code written against Jakarta Persistence or Jakarta CDI does not lock you to one vendor’s runtime.
  • Compliance: regulated industries often require standards-based platforms with predictable long-term support cycles.
  • Longevity: specifications evolve slower than any single product, which reduces the risk of sudden breaking changes.

How does enterprise Java differ from Java SE, and when does Spring matter?

Java SE gives you the JVM and core libraries: collections, streams, concurrency primitives, nothing enterprise-specific. Jakarta EE builds on top of it with APIs purpose-built for business applications: CDI for dependency injection, JPA for persistence, JMS for messaging, plus standardised security and transaction models. Spring Boot takes a different route: an opinionated framework with its own dependency injection container and auto-configuration, historically independent of the Jakarta specifications.

That independence has narrowed. Spring Boot 3.x runs on Jakarta EE specifications using the jakarta.* namespace, so Spring developers already consume Jakarta EE APIs whether they realise it or not.

Choosing between them often comes down to:

  • Team background: Spring’s ecosystem and documentation suit teams without prior application-server experience.
  • Library assumptions: third-party libraries built around Spring’s conventions can complicate a pure Jakarta EE deployment.
  • Deployment model: teams wanting a full-featured application server managing transactions and security tend to favour Jakarta EE directly.

What’s new in Jakarta EE 11 and which runtimes matter now?

Jakarta EE 11 brought Jakarta Data, a repository abstraction that reduces boilerplate for persistence code, alongside improved support for virtual threads and refinements to CDI. These are not cosmetic changes. Virtual threads, in particular, let high-concurrency workloads scale without the memory overhead of traditional thread-per-request models.

Jakarta EE concurrency and persistence illustration

Runtime choice now shapes outcomes as much as the specification itself. Quarkus optimises for fast startup and low memory, aimed squarely at containerised and serverless workloads. Payara, WildFly, and Open Liberty each offer full Jakarta EE compatibility with different tuning profiles for throughput, footprint, and operational tooling.

Before committing to a runtime, test:

  • Cold start time under realistic container resource limits.
  • Memory footprint at idle and under load.
  • Logging framework interactions, which practitioner migrations flag as a recurring source of surprises.
  • Transaction semantics, since behaviour can differ meaningfully between certified servers.

Can Jakarta EE run cloud-native on Kubernetes?

MicroProfile fills the gaps that Jakarta EE alone does not cover for microservices: externalised configuration, metrics, and health checks that align naturally with Kubernetes liveness and readiness probes. It complements Jakarta EE rather than replacing it, giving teams a pragmatic path to cloud-native patterns without abandoning the standard.

Packaging choices carry real operational weight:

  1. Fat JAR with embedded runtime (common with Quarkus): simpler deployment, but you own the runtime lifecycle inside your image.
  2. WAR deployed to an external application server: more separation of concerns, useful where a platform team manages the server centrally.
  3. Native image compilation: faster startup, smaller footprint, at the cost of longer build times and occasional reflection quirks.

During testing, verify MicroProfile Health endpoints respond correctly under load, metrics export cleanly to your observability stack, and configuration reloads behave as expected across restarts.

Is Jakarta EE ready for AI and agentic workloads?

The current consensus among Eclipse Foundation contributors is that Jakarta EE applications can integrate large language models today, through existing APIs combined with libraries that add higher-level abstraction over provider calls. There is no need to wait for a dedicated AI specification to start shipping features.

Jakarta EE applications can already integrate LLMs and AI capabilities through existing APIs and libraries. Initiatives such as Jakarta Agentic AI are working to standardise agentic programming models for enterprise Java, according to the Eclipse Foundation’s own assessment.

Libraries such as OmniHai and LangChain4j give Java developers structured ways to call model providers without hand-rolling HTTP clients for every integration. Jakarta Agentic AI, meanwhile, is the effort aimed at standardising how agentic workflows get built on the platform, and early signals suggest it will lean on dependency-injection patterns Java developers already know, treating AI services as managed, configurable components rather than bolted-on scripts.

Practical patterns worth adopting now:

  • Wrap provider calls behind an adapter interface so switching models does not ripple through business logic.
  • Manage AI service clients through CDI, with lifecycle and configuration handled the same way as any other injected bean.
  • Treat prompts and model responses as data requiring the same governance and audit discipline as any other sensitive payload.

How should teams choose between Jakarta EE and alternatives?

The decision rarely comes down to one factor. Weigh these axes together:

  • Portability needs: strict multi-vendor requirements favour Jakarta EE’s standards model.
  • Team experience: existing Spring expertise reduces short-term friction.
  • Library ecosystem: check whether critical third-party dependencies assume Spring conventions.
  • Startup and scale constraints: serverless or high-density container environments push towards Quarkus or similarly optimised runtimes.
  • Regulatory or contractual requirements: some public-sector or long-term contracts mandate standards compliance explicitly.

Run a short evaluation before committing. Test start-up time, throughput under sustained load, logging and observability integration, and transaction behaviour across at least two candidate runtimes.

Pro Tip: Run a short “runtime compatibility sprint” before full migration. Practitioner reports show that CDI behaviour with transactions, logging manager interactions, and third-party libraries assuming Spring semantics are the most frequent causes of delay, so surfacing them early on a small module saves weeks later.

Where should you start with Jakarta EE?

Start small and concrete rather than reading specifications end to end. A workable first sprint:

  • Pick one modern runtime (Quarkus, Payara, WildFly, or Open Liberty) and deploy a sample Jakarta EE application locally.
  • Add one MicroProfile feature, health checks are the easiest entry point, and confirm it responds correctly.
  • Containerise the result and measure cold start and memory before adding complexity.
  • Consult the official Jakarta EE site for specifications, compatible implementations, and migration guidance before scaling the pilot.

Community forums, vendor documentation, and open-source example repositories fill most remaining gaps once the basics run cleanly.

What migration patterns actually show up in practice?

Every Jakarta EE migration I have reviewed follows a familiar arc: teams underestimate behavioural differences between runtimes far more than they underestimate the namespace change itself. CDI and transaction handling rarely behave identically across servers, and that gap causes more delay than the actual code rewrite. If you are weighing a migration or an AI integration path, an architecture review is worth having before you write a line of new code.

— Pepe F.

Get expert help with your Jakarta EE migration

Expert help with Jakarta EE migrations can benefit from having the engineers who scope your architecture review also build and support the result, to avoid loss in translation between assessment and delivery. That matters most when a migration touches transaction semantics, legacy libraries assuming Spring conventions, or AI features you want built on managed, testable components rather than bolted-on scripts.

Vicedomini Softworks

Our work spans architecture reviews, Jakarta EE and Spring Boot migrations, cloud-native refactors onto containerised runtimes, AI integration, and ongoing maintenance once your platform is live. If your team is evaluating a runtime switch, planning a migration sprint, or scoping an AI integration on top of an existing Java estate, take a look at our software engineering services and get in touch to discuss a scoped review of your current architecture.

Sources

For specifications and release notes, consult the official Jakarta EE site and the Eclipse Foundation’s working group charter. For migration trade-offs grounded in production experience, see the practitioner migration report referenced throughout this piece.

FAQ

Is Java EE still maintained?

No. Java EE was donated to the Eclipse Foundation in 2017 and renamed Jakarta EE; all active development now happens under that name and governance model.

What is the difference between Jakarta EE and Spring Boot?

Jakarta EE is a set of standardised, vendor-neutral specifications, while Spring Boot is an opinionated framework that, since version 3.x, runs on Jakarta EE’s own specifications under the jakarta.* namespace.

Does Jakarta EE support AI integration?

Yes. Jakarta EE applications can integrate large language models today through existing APIs and libraries such as OmniHai and LangChain4j, and the Jakarta Agentic AI initiative aims to standardise agentic programming models further.

Which Jakarta EE runtime should I choose?

It depends on your constraints: Quarkus favours fast startup and low memory for containers, while Payara, WildFly, and Open Liberty offer full compatibility with different operational profiles. Test start-up time, memory, and transaction behaviour before deciding.

Can Vicedomini Softworks help plan a Jakarta EE migration?

Yes. Vicedomini Softworks offers architecture reviews, migration planning, cloud-native refactoring, and AI integration for teams moving to or modernising within Jakarta EE, delivered directly by the engineers doing the work.