Backend interview prep

Start

Jakarta EE Basics Interview Questions and Answers

Master Jakarta EE fundamentals with production-ready interview questions covering specifications, application servers, dependency injection, transactions, WAR and EAR packaging, annotations, architecture, and senior-level best practices.

Introduction

Jakarta EE is a collection of standardized specifications for building secure, transactional, scalable, and maintainable enterprise Java applications.

It provides programming models and APIs for common enterprise requirements such as:

  • Dependency injection
  • REST APIs
  • Web applications
  • Database persistence
  • Transactions
  • Messaging
  • Validation
  • Security
  • JSON processing
  • Asynchronous execution
  • Batch processing
  • WebSocket communication

Instead of every team creating its own implementation for these capabilities, Jakarta EE defines common contracts that application-server vendors implement.

Popular Jakarta EE-compatible runtimes and servers include implementations based on platforms such as:

  • WildFly
  • Payara
  • Open Liberty
  • Eclipse GlassFish
  • Apache TomEE

Jakarta EE is widely used in:

  • Banking systems
  • Insurance applications
  • Government platforms
  • Telecommunications
  • Healthcare systems
  • Enterprise integration
  • Transaction-processing applications

Understanding Jakarta EE fundamentals is essential for interviews involving enterprise Java, application servers, REST APIs, persistence, messaging, and distributed systems.

This guide covers the 15 most frequently asked Jakarta EE Basics interview questions with code examples, Mermaid diagrams, production scenarios, common mistakes, and senior-level recommendations.

Q1. What is Jakarta EE?

Answer

Jakarta EE is a platform made up of specifications for developing enterprise Java applications.

It extends Java SE with APIs and programming models for:

  • Web development
  • REST services
  • Dependency injection
  • Persistence
  • Transactions
  • Messaging
  • Security
  • Validation
  • JSON processing
  • Batch jobs
  • WebSocket communication

Jakarta EE itself is not one single framework or server.

It defines standard APIs and behavior that compatible runtimes implement.

Architecture

flowchart TD
    A[Java Application] --> B[Jakarta EE APIs]
    B --> C[Jakarta EE Runtime]
    C --> D[Database]
    C --> E[Messaging System]
    C --> F[External Services]

Example REST Resource

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@Path("/customers")
public class CustomerResource {

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public String getCustomers() {
        return """
            [
              {
                "id": 101,
                "name": "Venu"
              }
            ]
            """;
    }
}

Why Interviewers Ask This

Interviewers want to confirm that you understand Jakarta EE as a standardized enterprise platform rather than one implementation.

Production Example

A banking application may use:

  • Jakarta REST for APIs
  • Jakarta Persistence for database access
  • CDI for dependency injection
  • Jakarta Transactions for transaction management
  • Jakarta Messaging for asynchronous events

Common Mistake

Describing Jakarta EE as only a web framework.

Senior Follow-up

Jakarta EE is specification-driven. Application code usually depends on standard APIs while the runtime provides the implementation.

Q2. What was Java EE, and why was it renamed Jakarta EE?

Answer

Java EE was the original enterprise Java platform.

After stewardship moved to the Eclipse Foundation, the platform was renamed Jakarta EE.

The platform continues the enterprise Java programming model, but modern APIs use the jakarta.* namespace.

Namespace Example

Older Java EE code:

import javax.persistence.Entity;
import javax.ws.rs.Path;

Modern Jakarta EE code:

import jakarta.persistence.Entity;
import jakarta.ws.rs.Path;

Migration Concept

flowchart LR
    A[Java EE] --> B[Enterprise Java Specifications]
    B --> C[Transferred to Eclipse Foundation]
    C --> D[Jakarta EE]
    D --> E[jakarta Namespace]

Important Migration Consideration

The namespace change affects:

  • Imports
  • Dependencies
  • Application-server compatibility
  • Third-party libraries
  • Build configuration
  • Deployment descriptors

Common Mistake

Assuming an application can migrate only by changing the server version.

Senior Follow-up

Migration requires verifying the complete dependency tree because libraries compiled against javax.* may not work directly with jakarta.* APIs.

Q3. What is the difference between Java SE and Jakarta EE?

Answer

Java SE provides the core Java language and standard runtime APIs.

Jakarta EE adds enterprise application specifications on top of Java SE.

Comparison

Java SE Jakarta EE
Core Java platform Enterprise Java platform
Collections REST APIs
Streams Dependency injection
Threads Transactions
JDBC ORM and persistence
File handling Messaging
Networking Security
Concurrency utilities Web containers
JVM runtime Application-server services

Relationship

flowchart TD
    A[Jakarta EE Application] --> B[Jakarta EE APIs]
    B --> C[Java SE APIs]
    C --> D[JVM]
    D --> E[Operating System]

Java SE Example

List<String> names =
    List.of("Venu", "Anvika", "Ayaan");

Jakarta EE Example

@RequestScoped
public class CustomerService {

    @Inject
    private CustomerRepository repository;
}

Common Mistake

Treating Java SE and Jakarta EE as competing technologies.

Senior Follow-up

Jakarta EE applications run on the Java SE platform and rely on Java SE language and runtime features.

Q4. What problems does Jakarta EE solve?

Answer

Jakarta EE solves common enterprise application concerns through standardized APIs.

Problems Addressed

  • Dependency management
  • HTTP request handling
  • REST API development
  • Transaction boundaries
  • Database persistence
  • Messaging
  • Security
  • Validation
  • Resource management
  • Concurrency
  • Configuration
  • Application lifecycle

Without a Platform

Every application would need to manually implement:

HTTP Server
Dependency Injection
Transaction Management
Connection Handling
Security
Validation
Serialization
Messaging Integration
Lifecycle Management

With Jakarta EE

flowchart TD
    A[Business Code] --> B[Jakarta EE Programming Model]
    B --> C[Container Services]
    C --> D[Transactions]
    C --> E[Security]
    C --> F[Persistence]
    C --> G[Messaging]
    C --> H[Lifecycle]

Production Example

A claims-processing service can focus on validating and processing claims while the container manages:

  • Request lifecycle
  • Dependency injection
  • Transactions
  • Database connections
  • Authentication
  • Message listeners

Common Mistake

Assuming Jakarta EE eliminates the need for architecture and database knowledge.

Senior Follow-up

Jakarta EE standardizes infrastructure behavior, but developers must still design transaction boundaries, data models, error handling, scaling, and observability.

Q5. What are the major Jakarta EE specifications?

Answer

Jakarta EE includes multiple specifications, each solving a specific enterprise problem.

Common Specifications

Specification Purpose
Jakarta CDI Dependency injection
Jakarta REST RESTful APIs
Jakarta Servlet HTTP request processing
Jakarta Persistence ORM and database persistence
Jakarta Transactions Transaction management
Jakarta Messaging Asynchronous messaging
Jakarta Bean Validation Data validation
Jakarta Security Authentication and authorization
Jakarta JSON Binding Java-to-JSON mapping
Jakarta JSON Processing JSON parsing and generation
Jakarta WebSocket Real-time communication
Jakarta Batch Batch-processing applications
Jakarta Concurrency Managed asynchronous execution

Specification Map

flowchart TD
    A[Jakarta EE] --> B[Web]
    A --> C[Business]
    A --> D[Data]
    A --> E[Integration]
    A --> F[Security]

    B --> G[Servlet]
    B --> H[REST]
    B --> I[WebSocket]

    C --> J[CDI]
    C --> K[Transactions]
    C --> L[Bean Validation]

    D --> M[Persistence]
    D --> N[JSON Binding]

    E --> O[Messaging]
    E --> P[Batch]
    E --> Q[Concurrency]

    F --> R[Jakarta Security]

Common Mistake

Trying to memorize only specification names without understanding their responsibilities.

Senior Follow-up

A good architecture uses specifications together while keeping business logic independent of infrastructure APIs where practical.

Q6. What is a Jakarta EE application server?

Answer

A Jakarta EE application server is a runtime that implements Jakarta EE specifications and provides managed enterprise services.

Server Responsibilities

  • Application deployment
  • Dependency injection
  • HTTP request processing
  • Transaction management
  • Database resource management
  • Messaging integration
  • Security
  • Application lifecycle
  • Thread management
  • Connection pooling
  • Monitoring integration

Deployment Flow

flowchart TD
    A[Application Archive] --> B[Application Server]
    B --> C[Scan Annotations]
    C --> D[Create Managed Components]
    D --> E[Inject Dependencies]
    E --> F[Register REST and Servlet Endpoints]
    F --> G[Application Ready]

Examples of Services

DataSource
Transaction Manager
JMS Connection Factory
Security Realm
HTTP Listener
Thread Pool
Connection Pool

Production Example

A WildFly or Payara server can deploy an application archive and automatically provide transactions, CDI, JPA, REST, and security integration.

Common Mistake

Thinking the application server only hosts WAR files.

Senior Follow-up

The server is responsible for container-managed services that would otherwise have to be configured and managed by the application.

Q7. What is the difference between an application server and a Servlet container?

Answer

A Servlet container primarily supports web specifications such as Servlets and HTTP request processing.

A full Jakarta EE application server supports a broader set of enterprise specifications.

Comparison

Servlet Container Jakarta EE Application Server
Servlet support Servlet support
HTTP request handling REST APIs
Web deployment CDI
Basic session management JPA
Filters and listeners Transactions
Limited enterprise services Messaging
Security
Managed concurrency
Batch processing

Architecture

flowchart LR
    A[Servlet Container] --> B[Servlets]
    A --> C[Filters]
    A --> D[HTTP Sessions]

    E[Jakarta EE Server] --> B
    E --> C
    E --> D
    E --> F[CDI]
    E --> G[JPA]
    E --> H[JMS]
    E --> I[Transactions]
    E --> J[Security]

Example

A lightweight Servlet container may require additional libraries for:

  • Dependency injection
  • Persistence
  • REST
  • Messaging
  • Transactions

A Jakarta EE server provides standardized integrations for these capabilities.

Common Mistake

Assuming every Java web server is a full Jakarta EE server.

Senior Follow-up

Choose the runtime according to application requirements, operational model, startup needs, deployment model, and team expertise.

Q8. What is the role of annotations in Jakarta EE?

Answer

Annotations declare how classes and methods participate in container-managed behavior.

Common Annotations

@Path("/orders")
@ApplicationScoped
public class OrderResource {

    @Inject
    private OrderService orderService;

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<OrderResponse> getOrders() {
        return orderService.findOrders();
    }
}

Annotation Responsibilities

Annotation Purpose
@Path Defines REST path
@GET Maps HTTP GET
@Inject Injects dependency
@ApplicationScoped Defines CDI scope
@Entity Marks persistent entity
@Transactional Defines transaction boundary
@NotNull Adds validation rule
@RolesAllowed Restricts access

Container Processing

flowchart TD
    A[Annotated Class] --> B[Container Scans Metadata]
    B --> C[Register Managed Bean]
    B --> D[Register REST Endpoint]
    B --> E[Configure Transaction]
    B --> F[Apply Security Rules]
    B --> G[Apply Validation]

Common Mistake

Using many annotations without understanding the runtime behavior they activate.

Senior Follow-up

Annotations should express clear intent. Cross-cutting behavior such as security, transactions, and interception should remain predictable and documented.

Q9. What is dependency injection in Jakarta EE?

Answer

Dependency injection allows the container to create and provide required objects instead of application code constructing them manually.

Jakarta EE commonly uses CDI for dependency injection.

Example

@ApplicationScoped
public class CustomerService {

    private final CustomerRepository repository;

    @Inject
    public CustomerService(
        CustomerRepository repository
    ) {
        this.repository = repository;
    }

    public List<Customer> findAll() {
        return repository.findAll();
    }
}

Without Dependency Injection

CustomerRepository repository =
    new CustomerRepository();

CustomerService service =
    new CustomerService(repository);

With CDI

flowchart TD
    A[Container Starts] --> B[Discover CustomerRepository]
    B --> C[Discover CustomerService]
    C --> D[Resolve Constructor Dependency]
    D --> E[Inject CustomerRepository]
    E --> F[Managed CustomerService Ready]

Benefits

  • Loose coupling
  • Easier testing
  • Centralized lifecycle management
  • Interceptor support
  • Scope management
  • Cleaner component composition

Common Mistake

Using field injection everywhere.

Senior Follow-up

Constructor injection makes required dependencies explicit and generally improves testability and immutability.

Q10. What is the Jakarta EE application architecture?

Answer

A common Jakarta EE architecture separates HTTP handling, business logic, persistence, and integration concerns.

Layered Architecture

flowchart TD
    A[Client] --> B[REST Resource or Servlet]
    B --> C[Application Service]
    C --> D[Repository]
    D --> E[Jakarta Persistence]
    E --> F[Database]

    C --> G[Messaging Producer]
    G --> H[Message Broker]

    B --> I[Bean Validation]
    C --> J[Transactions]
    B --> K[Security]

Typical Layers

API Layer

  • REST resources
  • Servlets
  • Request DTOs
  • Response DTOs
  • HTTP status handling

Service Layer

  • Business use cases
  • Transaction boundaries
  • Authorization rules
  • Workflow orchestration

Persistence Layer

  • Entities
  • Repositories
  • JPQL or Criteria queries
  • Database interaction

Integration Layer

  • Messaging
  • External REST clients
  • Batch jobs
  • File processing

Package Example

com.codewithvenu.customer/
│
├── api/
│   ├── CustomerResource.java
│   ├── CreateCustomerRequest.java
│   └── CustomerResponse.java
│
├── application/
│   └── CustomerService.java
│
├── domain/
│   └── Customer.java
│
├── persistence/
│   └── CustomerRepository.java
│
└── integration/
    └── CustomerEventPublisher.java

Common Mistake

Placing business logic directly inside REST resources or Servlets.

Senior Follow-up

Resource classes should handle protocol concerns while services own business workflows and transactions.

Q11. What are WAR, JAR, and EAR files?

Answer

Jakarta EE applications can be packaged using different Java archive formats.

WAR

WAR stands for Web Application Archive.

It commonly contains:

  • Servlets
  • REST resources
  • CDI beans
  • Web files
  • Application classes
  • Libraries
customer-app.war

JAR

JAR stands for Java Archive.

It can contain:

  • Business components
  • Shared libraries
  • Entities
  • Utility classes
  • CDI beans
customer-domain.jar

EAR

EAR stands for Enterprise Application Archive.

It can package multiple modules together.

enterprise-platform.ear
│
├── customer-api.war
├── billing-module.jar
└── shared-domain.jar

Packaging Diagram

flowchart TD
    A[EAR] --> B[WAR Module]
    A --> C[JAR Module]
    A --> D[Shared Library]

    B --> E[REST and Web Layer]
    C --> F[Business Components]
    D --> G[Shared Domain Classes]

Modern Deployment

Many modern Jakarta EE applications are packaged as one deployable WAR or executable runtime image rather than large multi-module EAR deployments.

Common Mistake

Assuming EAR packaging is mandatory for enterprise applications.

Senior Follow-up

Packaging should reflect deployment independence, runtime boundaries, team ownership, and operational requirements.

Q12. What is convention over configuration in Jakarta EE?

Answer

Convention over configuration means the platform provides standard defaults so developers need less explicit configuration.

Examples

  • Annotations replace large XML files.
  • CDI discovers eligible beans.
  • REST resources are registered through annotations.
  • JPA maps class and field names using defaults.
  • Bean Validation discovers constraints automatically.
  • Transaction interceptors apply container behavior.

Example Entity

@Entity
public class Product {

    @Id
    private Long id;

    private String name;
}

Without additional configuration, default conventions may map:

Product class → Product table
name field → name column

Convention Flow

flowchart TD
    A[Developer Adds Standard Annotation] --> B[Container Applies Defaults]
    B --> C[Reduce XML Configuration]
    C --> D[Application Starts with Standard Behavior]

Explicit Configuration

Conventions can be overridden when required:

@Entity
@Table(name = "product_catalog")
public class Product {

    @Column(name = "product_name")
    private String name;
}

Common Mistake

Relying on defaults without understanding the generated database names or runtime behavior.

Senior Follow-up

Use conventions for simplicity, but override them explicitly when naming, performance, security, or compatibility requirements demand it.

Q13. How does Jakarta EE support transactions?

Answer

Jakarta EE supports declarative transaction management using Jakarta Transactions.

The container can begin, commit, or roll back transactions around business methods.

Example

@ApplicationScoped
public class TransferService {

    @PersistenceContext
    private EntityManager entityManager;

    @Transactional
    public void transfer(
        Long sourceId,
        Long destinationId,
        BigDecimal amount
    ) {

        Account source =
            entityManager.find(
                Account.class,
                sourceId
            );

        Account destination =
            entityManager.find(
                Account.class,
                destinationId
            );

        source.debit(amount);
        destination.credit(amount);
    }
}

Transaction Flow

sequenceDiagram
    participant Client
    participant Container
    participant Service
    participant Database
    Client->>Container: Invoke transfer
    Container->>Container: Begin transaction
    Container->>Service: Execute business method
    Service->>Database: Read and update accounts
    Database-->>Service: Results
    alt Method succeeds
        Container->>Database: Commit
        Container-->>Client: Success
    else Runtime failure
        Container->>Database: Rollback
        Container-->>Client: Error
    end

Benefits

  • Less transaction boilerplate
  • Consistent rollback behavior
  • Integration with persistence
  • Integration with messaging
  • Centralized transaction control

Common Mistake

Creating transaction boundaries around every repository method instead of the complete business operation.

Senior Follow-up

Transactions should protect business invariants and should avoid long-running remote calls while database resources are held.

Q14. What are common Jakarta EE interview mistakes?

Answer

Common mistakes include:

  • Treating Jakarta EE as one framework.
  • Confusing specifications with implementations.
  • Calling every web server an application server.
  • Assuming Jakarta EE replaces Java SE.
  • Ignoring the javax.* to jakarta.* namespace migration.
  • Putting business logic in REST resources.
  • Using field injection without understanding testability.
  • Returning entities directly from REST endpoints.
  • Keeping transactions open too long.
  • Creating unmanaged threads manually.
  • Ignoring container lifecycle rules.
  • Assuming all scopes are thread-safe.
  • Storing request-specific state in application-scoped beans.
  • Hardcoding database connections.
  • Ignoring generated SQL.
  • Treating container-managed resources like normal objects.
  • Depending heavily on implementation-specific APIs.
  • Ignoring deployment descriptors and server configuration.
  • Assuming a standard API guarantees identical operational behavior across servers.
  • Failing to understand class loading and deployment boundaries.

Scope Mistake Example

@ApplicationScoped
public class RequestDataHolder {

    private String currentCustomerId;
}

This bean is shared across requests and can cause race conditions.

Safer Request Scope

@RequestScoped
public class RequestDataHolder {

    private String currentCustomerId;
}

Scope Risk

flowchart TD
    A[Request 1] --> B[Shared Application Bean]
    C[Request 2] --> B
    B --> D[Mutable Request Data]
    D --> E[Race Condition and Data Leakage]

Interview Tip

Strong candidates understand both programming APIs and container-managed runtime behavior.

Q15. What are senior-level Jakarta EE best practices?

Answer

Senior developers should design Jakarta EE applications around clear boundaries, standard APIs, and predictable container behavior.

Best Practices

  • Prefer standard Jakarta EE APIs where practical.
  • Keep REST resources thin.
  • Place transaction boundaries in application services.
  • Use constructor injection for required dependencies.
  • Select CDI scopes carefully.
  • Avoid mutable shared state.
  • Use DTOs at API boundaries.
  • Keep entities inside the persistence layer.
  • Use Bean Validation for input validation.
  • Use container-managed threads and concurrency.
  • Avoid remote calls inside long database transactions.
  • Use messaging for asynchronous workflows.
  • Externalize configuration.
  • Use migration tools for schema changes.
  • Review generated SQL and query plans.
  • Add global exception mapping.
  • Apply role-based security at clear boundaries.
  • Design idempotent message consumers.
  • Add health checks and metrics.
  • Test against a compatible runtime.
  • Document implementation-specific dependencies.

Design Decision Flow

flowchart TD
    A[New Enterprise Requirement] --> B{Synchronous or Asynchronous?}

    B -->|Synchronous| C[REST or Servlet]
    B -->|Asynchronous| D[Jakarta Messaging]

    C --> E[Application Service]
    D --> E

    E --> F{Database Work?}
    F -->|Yes| G[Transactional Persistence]
    F -->|No| H[Business Processing]

    G --> I[DTO Response or Event]
    H --> I

    I --> J[Monitoring and Security]

Production Checklist

Clear API Contract
        │
        ▼
Correct CDI Scope
        │
        ▼
Service Transaction Boundary
        │
        ▼
Explicit Persistence Query
        │
        ▼
Validation and Security
        │
        ▼
Managed Resource Usage
        │
        ▼
Testing and Monitoring

Senior Follow-up

A strong Jakarta EE architecture uses container services deliberately while keeping business logic portable, testable, and independent of server-specific APIs where possible.

Jakarta EE Platform Architecture

flowchart TD
    A[Clients] --> B[HTTP Layer]
    B --> C[Jakarta REST]
    B --> D[Jakarta Servlet]

    C --> E[CDI Business Services]
    D --> E

    E --> F[Jakarta Transactions]
    E --> G[Bean Validation]
    E --> H[Jakarta Security]

    F --> I[Jakarta Persistence]
    F --> J[Jakarta Messaging]

    I --> K[Relational Database]
    J --> L[Message Broker]

Jakarta EE Request Lifecycle

sequenceDiagram
    participant Client
    participant Server
    participant Security
    participant Resource
    participant Service
    participant Database
    Client->>Server: HTTP Request
    Server->>Security: Authenticate and authorize
    Security-->>Server: Access decision
    Server->>Resource: Invoke REST resource
    Resource->>Resource: Validate request
    Resource->>Service: Execute use case
    Service->>Database: Transactional operation
    Database-->>Service: Result
    Service-->>Resource: Response DTO
    Resource-->>Server: HTTP response
    Server-->>Client: JSON response

Jakarta EE Component Model

flowchart TD
    A[Container] --> B[REST Resource]
    A --> C[CDI Bean]
    A --> D[Persistence Context]
    A --> E[Message Listener]
    A --> F[Security Context]

    B --> G[Inject Service]
    C --> H[Inject Repository]
    H --> D
    E --> C
    F --> B

Specification vs Implementation

flowchart TD
    A[Jakarta EE Specification] --> B[Defines API and Behavior]
    B --> C[Runtime Implementation]
    C --> D[WildFly]
    C --> E[Payara]
    C --> F[Open Liberty]
    C --> G[GlassFish]
    C --> H[TomEE]

    I[Application] --> A
    I --> C

Jakarta EE Layered Architecture

flowchart LR
    A[Client] --> B[API Layer]
    B --> C[Application Service]
    C --> D[Domain Logic]
    C --> E[Repository]
    E --> F[Jakarta Persistence]
    F --> G[Database]
    C --> H[Messaging]
    H --> I[Broker]

CDI Injection Example

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;

@ApplicationScoped
public class OrderService {

    private final OrderRepository repository;
    private final OrderEventPublisher publisher;

    @Inject
    public OrderService(
        OrderRepository repository,
        OrderEventPublisher publisher
    ) {
        this.repository = repository;
        this.publisher = publisher;
    }

    public void createOrder(
        CreateOrderCommand command
    ) {

        Order order =
            Order.create(
                command.customerId(),
                command.items()
            );

        repository.save(order);
        publisher.publishCreated(order);
    }
}

REST Resource Example

import jakarta.inject.Inject;
import jakarta.validation.Valid;
import jakarta.ws.rs.Consumes;
import jakarta.ws.rs.POST;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.core.MediaType;
import jakarta.ws.rs.core.Response;

@Path("/orders")
@Consumes(MediaType.APPLICATION_JSON)
public class OrderResource {

    private final OrderService orderService;

    @Inject
    public OrderResource(
        OrderService orderService
    ) {
        this.orderService = orderService;
    }

    @POST
    public Response createOrder(
        @Valid CreateOrderRequest request
    ) {

        Long orderId =
            orderService.createOrder(
                request.toCommand()
            );

        return Response
            .status(Response.Status.CREATED)
            .entity(
                new CreateOrderResponse(
                    orderId
                )
            )
            .build();
    }
}

Jakarta Persistence Example

import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import jakarta.transaction.Transactional;

@ApplicationScoped
public class CustomerRepository {

    @PersistenceContext
    private EntityManager entityManager;

    @Transactional
    public void save(Customer customer) {
        entityManager.persist(customer);
    }

    public Optional<Customer> findById(
        Long customerId
    ) {
        return Optional.ofNullable(
            entityManager.find(
                Customer.class,
                customerId
            )
        );
    }
}

Packaging Comparison

Archive Main Purpose
JAR Java classes and reusable modules
WAR Web and REST application
EAR Multiple enterprise modules
RAR Resource adapter
Uber JAR Application plus embedded runtime
Container image Application and runtime deployment unit

CDI Scope Overview

Scope Typical Lifetime
@Dependent Same lifecycle as injection target
@RequestScoped One HTTP request
@SessionScoped One HTTP session
@ApplicationScoped Entire application
@ConversationScoped Explicit conversation
Custom scope Application-defined lifecycle

Managed vs Unmanaged Object

flowchart LR
    A[new Service()] --> B[Unmanaged Object]
    B --> C[No Automatic Injection]
    B --> D[No Interceptors]
    B --> E[No Scope Management]

    F[Container Creates Service] --> G[Managed Bean]
    G --> H[Dependency Injection]
    G --> I[Transactions]
    G --> J[Security and Interceptors]

Creating a CDI bean manually with new bypasses container-managed behavior.

Application Server Responsibilities

flowchart TD
    A[Application Server] --> B[Deployment]
    A --> C[Dependency Injection]
    A --> D[Transactions]
    A --> E[Security]
    A --> F[Persistence]
    A --> G[Messaging]
    A --> H[Thread Management]
    A --> I[Connection Pooling]
    A --> J[Lifecycle]

Jakarta EE vs Framework Library

Jakarta EE Platform Standalone Framework Library
Standardized specifications Library-specific APIs
Runtime implements services Application assembles services
Container-managed lifecycle Application-managed lifecycle
Portable APIs Framework-specific behavior
Integrated transactions Separate integration may be needed
Compatibility certification Version-specific compatibility

Common Enterprise Use Case

flowchart TD
    A[Customer Submits Claim] --> B[Jakarta REST Resource]
    B --> C[Bean Validation]
    C --> D[Claim Service]
    D --> E[Jakarta Transaction]
    E --> F[Persist Claim]
    E --> G[Publish Claim Event]
    F --> H[Database]
    G --> I[Message Broker]
    I --> J[Fraud Check Consumer]
    I --> K[Notification Consumer]

Interview Quick Revision

Concept Purpose
Jakarta EE Enterprise Java platform
Specification Defines standard API behavior
Implementation Provides runtime behavior
Java SE Core Java platform
Application Server Managed enterprise runtime
Servlet Container HTTP and Servlet runtime
CDI Dependency injection
Jakarta REST RESTful APIs
Jakarta Persistence ORM and persistence
Jakarta Transactions Transaction management
Jakarta Messaging Asynchronous messaging
Bean Validation Input and model validation
WAR Web application archive
EAR Multi-module enterprise archive
Annotation Declares container behavior

Key Takeaways

  • Jakarta EE is a standardized enterprise Java platform built on top of Java SE.
  • It provides specifications for dependency injection, REST, Servlets, persistence, transactions, messaging, validation, security, JSON, batch processing, and concurrency.
  • Jakarta EE defines APIs and behavior, while compatible application servers provide implementations.
  • Java EE evolved into Jakarta EE, and modern APIs use the jakarta.* namespace.
  • Java SE and Jakarta EE are complementary rather than competing platforms.
  • An application server provides container-managed services such as transactions, security, persistence, messaging, thread management, and resource pooling.
  • A Servlet container provides web functionality but may not implement the complete Jakarta EE platform.
  • Annotations allow developers to declare REST endpoints, scopes, validation, transactions, security, and persistence behavior.
  • CDI provides dependency injection and managed component lifecycles.
  • Jakarta EE applications commonly use layered architecture with resources, services, repositories, entities, DTOs, and integration components.
  • WAR files package web applications, JAR files package reusable modules, and EAR files package multiple enterprise modules.
  • Convention over configuration reduces repetitive XML while allowing explicit overrides.
  • Jakarta Transactions allows containers to manage commit and rollback behavior around business methods.
  • Business logic should remain in services rather than REST resources or Servlets.
  • Mutable request-specific data must not be stored in shared application-scoped beans.
  • Managed components should not be created manually with new when dependency injection, transactions, or interceptors are required.
  • Senior developers use standard APIs where practical, select CDI scopes carefully, keep transaction boundaries clear, use DTOs, and monitor runtime behavior.