-
-
-
-
-
- Code Comparison
-
-
-
-
-
@Stateless
-public class OrderEJB {
- @EJB
- private InventoryEJB inventory;
-
- public void placeOrder(Order order) {
- // container-managed transaction
- inventory.reserve(order.getItem());
- }
-}
-
-
-
-
-
-
@ApplicationScoped
-public class OrderService {
- @Inject
- private InventoryService inventory;
-
- @Transactional
- public void placeOrder(Order order) {
- inventory.reserve(order.getItem());
- }
-}
-
-
-
Why the modern way wins
-
-
-
🪶
-
Lightweight
-
CDI beans are plain Java classes with no EJB-specific interfaces or descriptors.
-
-
-
💉
-
Unified injection
-
@Inject works for every managed bean, JAX-RS resources, and Jakarta EE components alike.
-
-
-
🧪
-
Easy unit testing
-
Plain classes without EJB proxy overhead are straightforward to instantiate and mock.
-
-
-
-
-
Modern Approach
-
CDI Bean
-
-
-
-
Difficulty
-
intermediate
-
-
JDK Support
-
-
EJB versus CDI
-
Available
-
Widely available since Jakarta EE 8 / Java 11
-
How it works
- CDI (Contexts and Dependency Injection) provides the same dependency injection and transaction management as EJBs, but as plain Java classes with no container-specific interfaces or superclasses. Scopes like @ApplicationScoped and @RequestScoped control lifecycle, and @Transactional replaces mandatory EJB transaction semantics.
-
-
-
- Related Documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Code Comparison
-
-
-
-
-
String sql = "SELECT * FROM users WHERE id = ?";
-try (Connection con = dataSource.getConnection();
- PreparedStatement ps =
- con.prepareStatement(sql)) {
- ps.setLong(1, id);
- ResultSet rs = ps.executeQuery();
- if (rs.next()) {
- User u = new User();
- u.setId(rs.getLong("id"));
- u.setName(rs.getString("name"));
- }
-}
-
-
-
-
-
-
@PersistenceContext
-EntityManager em;
-
-public User findUser(Long id) {
- return em.find(User.class, id);
-}
-
-public List<User> findByName(String name) {
- return em.createQuery(
- "SELECT u FROM User u WHERE u.name = :name",
- User.class)
- .setParameter("name", name)
- .getResultList();
-}
-
-
-
Why the modern way wins
-
-
-
🗺️
-
Object mapping
-
Entities are plain annotated classes — no manual ResultSet-to-object translation.
-
-
-
🔒
-
Type-safe queries
-
JPQL operates on entity types and fields rather than raw table and column strings.
-
-
-
⚡
-
Built-in caching
-
First- and second-level caches reduce database round-trips automatically.
-
-
-
-
-
Modern Approach
-
JPA EntityManager
-
-
-
-
Difficulty
-
intermediate
-
-
JDK Support
-
-
JDBC versus JPA
-
Available
-
Widely available since Jakarta EE 8 / Java 11
-
How it works
- JPA (Jakarta Persistence API) maps Java objects to database rows, eliminating manual ResultSet processing and SQL string concatenation. EntityManager provides find(), persist(), and JPQL queries so you work with domain objects instead of raw SQL, while the container manages connection pooling and transactions.
-
-
-
- Related Documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Code Comparison
-
-
-
-
-
@PersistenceContext
-EntityManager em;
-
-public User findById(Long id) {
- return em.find(User.class, id);
-}
-
-public List<User> findByName(String name) {
- return em.createQuery(
- "SELECT u FROM User u WHERE u.name = :name",
- User.class)
- .setParameter("name", name)
- .getResultList();
-}
-
-public void save(User user) {
- em.persist(user);
-}
-
-
-
-
-
-
@Repository
-public interface Users extends CrudRepository<User, Long> {
- List<User> findByName(String name);
-}
-
-
-
Why the modern way wins
-
-
-
🪄
-
Zero boilerplate
-
Declare the interface; the container generates the full DAO implementation at deploy time.
-
-
-
🔍
-
Derived queries
-
Method names like findByNameAndStatus are parsed automatically — no JPQL or SQL needed.
-
-
-
🔌
-
Portable
-
Any Jakarta EE 11 compliant runtime provides the repository implementation with no vendor lock-in.
-
-
-
-
Old Approach
-
JPA EntityManager
-
-
-
Modern Approach
-
Jakarta Data Repository
-
-
-
-
Difficulty
-
intermediate
-
-
JDK Support
-
-
JPA versus Jakarta Data
-
Available
-
Available since Jakarta EE 11 / Java 21 (2024)
-
How it works
- Jakarta Data (Jakarta EE 11) turns data access into a pure interface declaration. You annotate an interface with @Repository and extend a built-in repository type such as CrudRepository. The runtime generates the implementation — including derived queries from method names like findByName — so there is no EntityManager boilerplate, no JPQL strings, and no hand-written save/find methods.
-
-
-
- Related Documentation
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Code Comparison
-
-
-
-
-
@WebServlet("/users")
-public class UserServlet extends HttpServlet {
- @Override
- protected void doGet(HttpServletRequest req,
- HttpServletResponse res)
- throws ServletException, IOException {
- String id = req.getParameter("id");
- res.setContentType("application/json");
- res.getWriter().write("{\"id\":\"" + id + "\"}");
- }
-}
-
-
-
-
-
-
@Path("/users")
-public class UserResource {
- @GET
- @Produces(MediaType.APPLICATION_JSON)
- public Response getUser(
- @QueryParam("id") String id) {
- return Response.ok(new User(id)).build();
- }
-}
-
-
-
Why the modern way wins
-
-
-
📐
-
Declarative routing
-
Annotations define HTTP method, path, and content type instead of imperative if/else dispatch.
-
-
-
🔄
-
Automatic marshalling
-
Return POJOs directly; the runtime serialises them to JSON or XML based on @Produces.
-
-
-
🧪
-
Easier testing
-
Resource classes are plain Java objects, testable without a servlet container.
-
-
-
-
Old Approach
-
HttpServlet
-
-
-
Modern Approach
-
JAX-RS Resource
-
-
-
-
Difficulty
-
intermediate
-
-
JDK Support
-
-
Servlet versus JAX-RS
-
Available
-
Widely available since Jakarta EE 8 / Java 11
-
How it works
- JAX-RS (Jakarta RESTful Web Services) lets you expose REST endpoints using simple annotations like @GET, @Path, and @Produces. No more manual parsing of request parameters or setting content types on the response — the runtime handles marshalling and routing automatically.
-
-
-
- Related Documentation
-
-
-
-
-
-
-
-
-