Jakarta EE vs Spring Boot in 2026: I Migrated a Production Backend and the Tradeoffs Aren't What You'd Expect

Jakarta EE 11 launched with a refreshed pitch around portability, independent runtimes, and alignment with the latest JVM specs. The Java community responded with its usual enthusiasm: "Spring is bloated, we're going back to standards." I read all of it. And then I did something most people don't: I migrated a real module from a digital signature backend I had running in production on Spring Boot 3.x, ported it to Payara 6 with Jakarta EE 11, measured everything I could measure, and documented what went wrong.

My thesis is this: Jakarta EE isn't dead, but the real migration cost is consistently higher than synthetic benchmarks promise. Spring Boot wins on ecosystem; Jakarta EE wins on real portability. Neither wins at everything, and the official documentation for both omits exactly the same problems.

Jakarta EE vs Spring Boot 2026: The Real State of the Ecosystem

Before any numbers, the technical context that actually matters:

• Spring Boot 3.x runs on Jakarta EE 9+ internally (it dropped javax.* in 3.0). That means the "Spring vs Jakarta EE" narrative is partially false: Spring Boot 3 is already Jakarta EE under the hood, with an abstraction layer on top.
• Jakarta EE 11 (official Release Notes) brings improved Virtual Threads support (Project Loom), Jakarta Data 1.0 as a new spec, and improvements to CDI 4.1. Real changes, not cosmetic ones.
• The actual debate isn't "which is better?" — it's "when does it make sense to pay the portability cost?"

You lose that nuance if you only read TechEmpower benchmarks or the comparisons floating around Reddit. I read those too. Then I went to the console.

The Real Migration: Before and After the REST Module

The module I migrated is a digital signature backend: REST endpoints for signing documents, verifying certificates, and managing tokens. Nothing experimental. Code that processes sensitive operations, with real integration tests and logs that matter.

Before: Spring Boot 3.x

<!-- pom.xml before the migration -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <!-- Spring Boot 3.x version active at the time of migration -->
    <version>3.3.0</version>
</parent>

<dependencies>
    <!-- Web + REST -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- Base security -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
    <!-- JPA with Hibernate -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
    <!-- PostgreSQL driver -->
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
    </dependency>
</dependencies>

A typical certificate validation endpoint looked like this:

// Spring Boot: signature verification endpoint
@RestController
@RequestMapping("/api/v1/signature")
public class SignatureController {

    private final SignatureService signatureService;

    // Constructor injection — best practice
    public SignatureController(SignatureService signatureService) {
        this.signatureService = signatureService;
    }

    @PostMapping("/verify")
    public ResponseEntity<VerificationResponse> verify(
            @RequestBody @Valid SignatureRequest request) {
        // The service throws a typed exception if the signature is invalid
        var result = signatureService.verify(request.getDocument(), request.getSignature());
        return ResponseEntity.ok(new VerificationResponse(result));
    }
}

Clean, direct. Zero extra boilerplate if Spring Boot is already configured.

After: Jakarta EE 11 on Payara 6

<!-- pom.xml post-migration to Jakarta EE 11 -->
<dependencies>
    <!-- Full Jakarta EE 11 spec — provided because the server supplies it -->
    <dependency>
        <groupId>jakarta.platform</groupId>
        <artifactId>jakarta.jakartaee-api</artifactId>
        <version>11.0.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

<!-- No fat JAR: Payara deploys the WAR -->
<packaging>war</packaging>

The same endpoint in Jakarta EE 11:

// Jakarta EE 11: same endpoint, different ceremony
@Path("/signature")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@ApplicationScoped
public class SignatureResource {

    @Inject
    SignatureService signatureService;

    @POST
    @Path("/verify")
    public Response verify(SignatureRequest request) {
        // No automatic @Valid — you need explicit Bean Validation or a CDI interceptor
        // That's boilerplate Spring Boot handles for you
        if (request == null || request.getDocument() == null) {
            return Response.status(Response.Status.BAD_REQUEST).build();
        }
        var result = signatureService.verify(request.getDocument(), request.getSignature());
        return Response.ok(new VerificationResponse(result)).build();
    }
}

The difference isn't dramatic in this one example, but it scales. With 30 endpoints, the accumulated manual configuration was higher than I expected.

Startup Benchmark on Railway: The Real Numbers

I ran both stacks on Railway (my Spring Boot in production post has the JVM flags baseline) with the same virtual hardware. The numbers are directional and context-dependent, but the trend was consistent across 5 runs:

The Jakarta EE WAR looks small on paper because the server supplies the specs. But the server itself is enormous. In ephemeral containers or frequent deployments, that hurts.

The JVM flags I used in both cases to align conditions:

# Flags used in both stacks for a fair comparison
-XX:+UseZGC \
-XX:MaxRAMPercentage=75.0 \
-XX:+UseStringDeduplication \
-Djava.security.egd=file:/dev/./urandom \
# Virtual Threads enabled (available in both with JDK 21+)
--enable-preview

With Virtual Threads, Jakarta EE 11 on Payara showed better throughput under sustained load than Spring Boot without WebFlux. But Spring Boot with WebFlux closes that gap almost entirely. Concurrency is no longer an exclusive advantage for either side.

The Three Problems No Official Guide Mentions

This is what I was looking for when I started this migration — and found documented nowhere.

Problem 1: CDI and the lifecycle in Jakarta Data 1.0 has edge cases with repositories without explicit transactions

Jakarta Data 1.0 is new in EE 11 (confirmed in the official spec) and the docs present it as the answer to Spring Data. It is, partly. But if you have repositories executing queries outside an active transactional context, the behavior isn't what the spec suggests in its examples. I spent two hours diagnosing a TransactionRequiredException that only showed up on the certificate verification path, not the signing path. The difference was that one had explicit @Transactional on the service and the other trusted CDI to resolve it. CDI doesn't resolve it on its own.

// ❌ This fails silently on Payara with Jakarta Data 1.0
// if the repository does a read query outside an active TX
@ApplicationScoped
public class CertificateService {

    @Inject
    CertificateRepository repo; // Jakarta Data repository

    public Optional<Certificate> find(String serial) {
        // Without @Transactional here, Payara throws at runtime
        // Spring Data JPA would have created the TX automatically
        return repo.findBySerial(serial);
    }
}

// ✅ Fix: explicit TX or annotation on the repository
@ApplicationScoped
public class CertificateService {

    @Inject
    CertificateRepository repo;

    @Transactional(Transactional.TxType.SUPPORTS) // accepts existing TX or runs without one
    public Optional<Certificate> find(String serial) {
        return repo.findBySerial(serial);
    }
}

Spring Boot per its official documentation creates read transactions automatically on Spring Data repositories. Opinionated? Yes. But in production, that default saves you from subtle bugs.

Problem 2: Third-party library integrations assume Spring in 2026

I wanted to integrate a PKI signing library (I won't name it because it's private, but the pattern is universal): the SDK had native Spring Boot integration via @SpringBootApplication autoconfiguration. For Jakarta EE, the README said "see manual integration docs." Those docs had three steps, two of which referenced APIs deprecated since EE 9. I ended up writing my own CDI adapter.

This isn't a Jakarta EE spec problem. It's an ecosystem problem. 80% of niche Java libraries assume Spring Boot. If you go pure EE, you're going to write adapters. Budget that time accordingly.

Problem 3: Structured logging is a first-class citizen in Spring Boot. It's not in EE 11.

With Spring Boot 3.x, structured JSON logging with trace correlation is three lines in application.properties. With Jakarta EE 11 on Payara, the native logging system (Java Util Logging) has no out-of-the-box support for structured JSON with MDC (Mapped Diagnostic Context). I had to manually add Logback as a dependency, configure a logback.xml inside the WAR, and hope Payara wouldn't interfere with its own log manager.

<!-- logback.xml inside the WAR for Jakarta EE on Payara -->
<configuration>
    <appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <!-- Extra fields for trace correlation -->
            <customFields>{"app":"signature-backend","env":"production"}</customFields>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="JSON"/>
    </root>
</configuration>

And then I had to add this to payara-web.xml:

<!-- payara-web.xml: delegate logging to the app's system, not the server's -->
<payara-web-app>
    <log-service>
        <module-log-levels>
            <module name="com.sun.enterprise.server" value="WARNING"/>
        </module-log-levels>
    </log-service>
</payara-web-app>

None of this appears in the official migration guide. I found it in a 2023 Stack Overflow thread and a GitHub issue on the Payara repo itself.

Common Mistakes When Comparing These Two Stacks

Mistake 1: Comparing fat JAR vs WAR without counting the server. The Jakarta EE WAR looks lightweight, but the application server running it weighs between 150 MB and 400 MB deployed. The Spring Boot fat JAR includes everything — that's what makes the comparison honest.

Mistake 2: Assuming "standard" means "free portability." Jakarta EE promises portability across certified servers. In practice, Payara and WildFly have behavioral differences in CDI, deployment error handling, and logging extensions. Portability exists, but it's not free — you have to test against each server.

Mistake 3: Ignoring the ecosystem cost. If your stack has more than five third-party dependencies, do the exercise before migrating: check whether each one has native Jakarta EE integration or assumes Spring. This single point can disqualify the migration without running a single benchmark. The dependency supply chain topic in Java has its own complexity — I touched on a different angle of that when comparing npm vs PyPI as attack vectors.

Mistake 4: Believing Virtual Threads settle the performance comparison. With JDK 21+ and Virtual Threads, both stacks can handle massive concurrency without the traditional reactive model. The historical advantage of Netty/WebFlux over blocking servers has shrunk. But that doesn't make Jakarta EE faster at startup or easier to integrate.

FAQ: Jakarta EE vs Spring Boot in 2026

Does it make sense to migrate from Spring Boot to Jakarta EE today?
Depends on why. If you need real portability across application servers — an enterprise scenario where the client mandates WildFly on their own infrastructure — Jakarta EE makes sense. If you're on cloud with your own containers, Spring Boot probably saves you weeks of configuration without giving up anything significant.

Is Jakarta EE 11 better than Spring Boot 3.x for performance?
Under sustained load with Virtual Threads, the difference is small and workload-dependent. On startup time and time-to-first-request, Spring Boot with a fat JAR wins clearly in ephemeral container environments. Synthetic benchmarks don't capture the bootstrapping cost of the application server.

Can I use Spring Boot and Jakarta EE together?
Spring Boot 3.x already uses Jakarta EE internally (everything moved from javax.* to jakarta.* in version 3.0). What you can't easily do is mix Jakarta CDI with Spring's container in the same context. They're two different dependency injection models.

What application server do you recommend for Jakarta EE 11 in production?
Payara 6 has the most up-to-date documentation for EE 11 and the most active GitHub community at the time of writing. WildFly has more history and better general community support. Open Liberty (IBM) is solid for enterprise environments but has less documentation in English. None of them have the Railway experience that Spring Boot has today.

Can Jakarta Data 1.0 replace Spring Data JPA?
Partially. It covers the basic typed repository use cases. But Spring Data has five more years of maturity, integration with the entire Spring ecosystem, and a much larger plugin community. Jakarta Data 1.0 is promising; it's not a drop-in replacement yet.

Why does the official documentation for both omit the same problems?
Because official documentation is written for the happy path. Logging problems in Payara containers, CDI edge cases without an active transaction, and the cost of adapting third-party libraries — these are problems that show up when you put code into real production. No documentation team systematically reproduces that scenario.

What I'd Do Differently Starting Today

I don't regret doing the migration. I learned things I wouldn't have learned just reading specs. But if someone asks me whether it's worth it today, my answer is nuanced:

Stick with Spring Boot 3.x if:

• You have a team that already knows the ecosystem
• You use third-party libraries that assume Spring
• You deploy in your own containers or on Railway
• Startup time matters (serverless, fast scaling)

Evaluate Jakarta EE 11 if:

• You have contractual portability requirements across certified servers
• You're in an enterprise environment where WildFly or Payara already run on the client's infrastructure
• You want cleaner architectural separation between application code and the runtime
• You have time to absorb the manual configuration curve

What I wouldn't do is make the decision based on synthetic benchmarks. The numbers that matter are yours — with your hardware, with your dependencies. The ones I measured are a starting point, not a conclusion.

I resisted TypeScript for years thinking types were bureaucracy. A null pointer bug at 2am convinced me in 20 minutes. Jakarta EE gave me something similar: the portability is real, but so is the adaptation cost. Both things can be true at the same time.

The path to becoming a serious Java practitioner doesn't run through picking the right stack. It runs through deeply understanding both, knowing when to use each one, and not lying to yourself about the tradeoffs. That's what this post is my contribution toward.

If you're interested in the security side of digital identity and signing systems, the post on Themis vs Web Crypto API covers similar tradeoffs but in TypeScript. And if you want to see how my JVM flags architecture looked before this migration, it's documented in Spring Boot in production: what the official docs leave out.

Sources:

• Jakarta EE 11 Release Notes — jakarta.ee/release/11/
• Spring Boot 3.x Reference Documentation — docs.spring.io

This article was originally published on juanchi.dev