Jakarta EE Overview

What is Jakarta EE — and Why Should a Spring Developer Care?

Jakarta EE is a collection of specifications — not a library, not a framework, not a product. Each specification defines an API (interfaces, annotations, contracts) that vendors implement. JPA defines @Entity and EntityManager; Hibernate is one implementation. Servlet defines HttpServletRequest; Tomcat is one implementation. The spec itself ships no runnable code.

This distinction matters because you are already using Jakarta EE specifications in every Spring Boot project. When you write @Entity, @NotBlank, or HttpServletRequest, those annotations come from Jakarta EE specs (jakarta.persistence, jakarta.validation, jakarta.servlet). Spring doesn't reinvent these — it implements or builds on top of them. Understanding Jakarta EE is understanding the foundations Spring sits on.

History — Java EE, the Oracle Handoff, and the javax→jakarta Rename

/*
 * 1999  J2EE 1.2 — first enterprise platform, Servlets + EJB + JMS
 * 2006  Java EE 5 — annotations replace XML-heavy config; JPA introduced
 * 2009  Java EE 6 — CDI introduced; EJB simplified; REST (JAX-RS)
 * 2013  Java EE 7 — WebSocket, JSON-P, Batch
 * 2017  Java EE 8 — HTTP/2, JSON-B, Security API
 *                    Oracle donates the platform to the Eclipse Foundation
 *                    → Project renamed to Jakarta EE
 * 2019  Jakarta EE 8 — identical to Java EE 8, just new governance
 * 2020  Jakarta EE 9 — THE BREAKING CHANGE: javax.* → jakarta.*
 * 2022  Jakarta EE 10 — Java 11+, CDI Lite, Core Profile
 * 2024  Jakarta EE 11 — Java 21+, Virtual Threads, JPA 3.2
 */

// Before Jakarta EE 9 / Spring Boot 2.x
import javax.persistence.Entity;
import javax.validation.constraints.NotBlank;
import javax.servlet.http.HttpServletRequest;

// Jakarta EE 9+ / Spring Boot 3+
import jakarta.persistence.Entity;
import jakarta.validation.constraints.NotBlank;
import jakarta.servlet.http.HttpServletRequest;

What is a Bean?

The word "bean" is overloaded across Java's history and means different things in different contexts. Before conflating them, it helps to distinguish them clearly:

// CDI bean — container creates, injects, and manages lifecycle
@ApplicationScoped
public class UserService {

    @Inject
    private UserRepository repository;  // injected by container — never null after @PostConstruct

    @PostConstruct  // called AFTER injection is complete — safe to use injected fields here
    public void init() {
        log.info("UserService ready, repository={}", repository);
    }

    @PreDestroy  // called before container destroys the instance — clean up resources
    public void cleanup() {
        // release resources if needed
    }
}

// WRONG — this is just a regular object, no injection, no lifecycle
UserService svc = new UserService();  // repository is null — will NPE on first call

CDI Scopes — How Long a Bean Lives

@RequestScoped      // one instance per HTTP request — destroyed when request ends
@SessionScoped      // one instance per HTTP session — destroyed when session expires
@ApplicationScoped  // one instance for the whole application — effectively a singleton
@ConversationScoped // developer-controlled scope — spans multiple requests explicitly
@Dependent          // default: same scope as the bean that injects it (no shared instance)

Jakarta EE Specifications You Already Use in Spring Boot

The following Jakarta EE specs are active in every standard Spring Boot 3.x project — not optionally, by default. This is the concrete answer to "why does this topic matter if I'm a Spring developer":

Application Servers vs Embedded Server — The Deployment Model Difference

/*
 * JAKARTA EE (traditional) — external application server:
 *
 *   [WildFly / Payara]
 *       └── runs permanently
 *       └── you deploy a WAR/EAR into it
 *       └── server provides: CDI, JPA, Transactions, Security, JMS...
 *       └── multiple apps can share one server
 *
 * SPRING BOOT — embedded server model:
 *
 *   [Your JAR]
 *       └── contains an embedded Tomcat/Jetty/Undertow
 *       └── java -jar myapp.jar → app starts its own server
 *       └── one app per JVM process (the 12-factor way)
 *       └── no external server dependency at runtime
 */

JSON in Jakarta EE — JSON-P, JSON-B, and Why Jackson Won

Jakarta EE defines two specs for JSON:

Both are valid specs, correctly designed, and implemented by libraries like Yasson (JSON-B) and Eclipse Parsson (JSON-P). They lost to Jackson in practice for three reasons: Jackson predated both specs and was already entrenched; Jackson's annotation model (@JsonProperty, @JsonIgnore) is richer and more flexible; and Spring Boot chose Jackson as its default HttpMessageConverter, which gave it the ecosystem momentum that compounds over time.

Jakarta EE Profiles — Full, Web, and Core

Jakarta EE is not monolithic — you don't have to use all specs. Profiles define which subset is required for certification:

<!-- Full Platform — compile against everything, server provides at runtime -->
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>  <!-- server provides at runtime -->
</dependency>

<!-- Web Profile only — smaller compile-time surface -->
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-web-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Interview Questions