Jakarta EE — Cheat Sheet

Tags: jakarta-ee, java, cdi, jpa, jax-rs, enterprise-java

Level: intermediate

TL;DR: Core enterprise Java standard providing vendor-neutral specifications for dependency injection, persistence, transactions, and RESTful web services.

Key concepts

Specification suite maintained by Eclipse Foundation, previously known as Java EE.

Package namespace migrated from javax.* to jakarta.* starting in Jakarta EE 9.

CDI (Contexts and Dependency Injection) manages bean lifecycle and type-safe dependency injection.

Jakarta RESTful Web Services (JAX-RS) builds HTTP endpoints using declarative annotations.

Jakarta Persistence (JPA) standardizes object-relational mapping and entity lifecycle management.

Jakarta Transactions (JTA) coordinates distributed and container-managed transaction boundaries.

Profiles define standard subsets: Web Profile for web applications, Core Profile for microservices.

Application servers provide runtime implementations: WildFly, Payara, Open Liberty, and GlassFish.

Decouples API interfaces from vendor runtime implementations through standard SPIs.

Typical questions and ready answers

Q: What is the practical difference between Java EE and Jakarta EE?R: Jakarta EE is the open-source evolution governed by the Eclipse Foundation after Oracle transferred the platform. The critical shift is the namespace migration from javax.* to jakarta.* in Jakarta EE 9.

Q: How does CDI differ from Spring's dependency injection container?R: CDI is a vendor-neutral standard specification integrated directly into the runtime, whereas Spring is an opinionated framework implementation. CDI relies on standard qualifiers, interceptors, and events out of the box.

Q: What is the role of an application server in modern containerized deployments?R: Runtimes like Open Liberty or WildFly Bootable Jar packages provide optimized, lightweight modular runtimes, packing only required Jakarta EE specifications inside container images.

Pitfalls and common mistakes

Mixing legacy javax.* imports with jakarta.* dependencies causes runtime class definition errors.

Forgetting a beans.xml marker file in CDI archives disables bean discovery unexpectedly.

Accessing lazy JPA associations outside active transaction boundaries triggers lazy initialization exceptions.

Injecting request-scoped beans into application-scoped beans without client proxies introduces concurrency race conditions.

Relying on vendor-specific extensions breaks portability across compliant Jakarta EE runtimes.

Snippets and commandsJava

```package com.example.api;

import jakarta.enterprise.context.ApplicationScoped;

import jakarta.inject.Inject;

import jakarta.ws.rs.GET;

import jakarta.ws.rs.Path;

import jakarta.ws.rs.Produces;

import jakarta.ws.rs.core.MediaType;

import jakarta.ws.rs.core.Response;

@Path("/users")

@ApplicationScoped

public class UserResource {

@Inject

private UserService userService;

@GET

@Produces(MediaType.APPLICATION_JSON)

public Response getAllUsers() {

return Response.ok(userService.findAll()).build();

}

}

```

To review

[ ] CDI bean discovery modes (annotated vs all) and producer methods.

[ ] JPA entity states: new, managed, detached, and removed.

[ ] Container-Managed Transactions (CMT) attributes: REQUIRED, REQUIRES_NEW.

[x] Package namespace migration from javax.* to jakarta.*.

[x] Differences between Core Profile, Web Profile, and Full Platform.

References

Eclipse Foundation Jakarta EE Official Specifications

Jakarta EE 10 Core Profile & Web Profile Specifications

Jakarta Contexts and Dependency Injection (CDI) Specification