For a long time, enterprise Java persistence has been approached as a largely stable area of the stack. Entities, an ORM, and a relational database were sufficient for many systems, and JPA became a widely adopted and reliable way to manage data access. That stability, however, has also shaped how persistence is still conceptualised today, even as the systems we build, and the data they rely on, have become significantly more complex.
As Otavio Santana, an award-winning software engineer, Java Champion, and long-time contributor to the Java ecosystem, says in an interview: “JPA didn’t break. JPA is still there, it’s well designed.” The real issue is not JPA itself, but the assumption that it should remain the default answer to every persistence problem.
He expands on this point by clarifying that the shift is driven by the persistence landscape itself rather than by shortcomings in JPA: “What happens is we have more flavours, more databases, more solutions around persistence in the enterprise. JPA is just one more flavour of a much bigger persistence universe.”
Modern enterprise systems no longer operate in a single-database world. Teams routinely combine relational databases, NoSQL stores, read-heavy APIs, and specialised data services. Persistence has become polyglot by necessity, not by trend. Yet many architectures are still designed around a JPA-centric mental model that struggles to adapt once systems grow, diversify, or change direction.
The Evolution of Persistence in Enterprise Java
This is the gap Jakarta EE 12 explicitly addresses. In his OCX 26 session, “From JDO to Jakarta Query: The Evolution of Persistence in Enterprise Java”, Otavio Santana will discuss how enterprise Java persistence evolved from entity-centric models to today’s repository and query-driven approach, and why that shift matters for systems being built now.
Rather than replacing JPA, Jakarta EE 12 expands the persistence toolbox. Jakarta Data introduces a more declarative, repository-centric approach that allows developers to focus on domain logic instead of persistence mechanics. Jakarta NoSQL recognises non-relational databases as first-class citizens in enterprise Java. Jakarta Query enables queries to be expressed in a storage-agnostic way, allowing providers to translate and optimise them for the underlying data store.
The shift is subtle but important. As Otavio explains, the goal is to be “more domain-centric” without sacrificing performance. Persistence becomes an implementation detail again, not something that dictates how the domain must be modelled.
The cost of clinging to outdated persistence assumptions is real: excessive boilerplate, tightly coupled domain code, and architectural decisions that become expensive to undo. Jakarta Data and Jakarta Query are not about abstraction for abstraction’s sake; they are about reducing cognitive load and making persistence choices explicit, flexible, and easier to evolve.
If you are making persistence decisions today that need to hold up over the next few years, this session is worth attending in person. You’ll gain a clear mental model for modern enterprise Java persistence, when JPA still fits, when it doesn’t, and how Jakarta Data and Jakarta Query change the trade-offs. You’ll leave with a practical framework for designing persistence layers that are domain-centric, polyglot, and ready for change.
If you haven’t already, register to attend OCX 26 in Brussels.
