Enterprise intermediate

JPA versus Jakarta Data

Declare a repository interface and let Jakarta Data generate the DAO implementation automatically.

✕ Jakarta EE 8+
@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);
}
✓ Jakarta EE 11+
@Repository
public interface Users extends CrudRepository<User, Long> {
    List<User> findByName(String name);
}
🪄

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
Since JDK
21
Difficulty
intermediate
JPA versus Jakarta Data
Available

Available since Jakarta EE 11 / Java 21 (2024)

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.

Share 𝕏 🦋 in