🔸 TLDR
- ▪️ Jakarta Query is standardizing one object-oriented query language with two levels (core + extended) so Persistence, Data, and NoSQL can stop evolving query languages in parallel.
🔸 CONTEXT
We’ve lived for years with:
- ▪️ JPQL in Jakarta Persistence (JPA)
- ▪️ JDQL in Jakarta Data (a subset for broader datastores)
The problem? Two specs, two evolutions, and eventually… drift.
Jakarta Query’s bet: define one common object-oriented query model that can be reused across Jakarta Persistence, Jakarta Data, and Jakarta NoSQL—instead of introducing “yet another isolated language”.
🔸 WHAT JAKARTA QUERY IS (AND ISN’T)
- ▪️ ✅ A specification that standardizes the syntax + semantics of the query language (including a core subset + an extended superset).
- ▪️ ✅ A way to align JCQL (core) with JPQL (extended) so providers can implement what fits their datastore.
- ▪️ ❌ Not a new Java API to execute queries: execution stays in existing APIs (EntityManager, @Repository, etc.).
- ▪️ ☕ Requires Java SE 21+ (per the 1.0 page).
Also: the 1.0-M1 spec doc is a Draft dated October 11, 2025.
🔸 CODE: SAME QUERY MODEL, DIFFERENT PLACES
1) Core-level query (portable mindset)
This is the kind of “core” query meant to be implementable across non-relational providers too.
2) Jakarta Data: embed the query in a repository
The @Query value is a string in JDQL or JPQL, with rules for named/positional parameters.
3) Jakarta Persistence (JPA): execute via EntityManager (JPQL / extended level)
Jakarta Query’s goal is to make the language definition reusable beyond “JPQL-only-inside-JPA”.
4) “Polyglot persistence” without rewriting your brain 🧠
The big win is that Jakarta Data repositories can target relational or NoSQL datastores while keeping a consistent query model (the provider translates to the native store).
🔸 WHY THIS MATTERS
- ▪️ 🔁 Less mental overhead: one query model instead of “JPQL vs JDQL vs store-specific”
- ▪️ 🧩 Portability: a core language that is realistic for NoSQL + an extended one for relational power
- ▪️ 🛠️ Better tooling & clearer semantics: spec explicitly aims to clarify ambiguities and rigorously define behavior
- ▪️ 🚀 Fits the direction of Jakarta EE 12 work (Query + Data + NoSQL integration is actively discussed)
🔸 TAKEAWAYS
- ▪️ 🧠 Think “one query model”, multiple execution APIs (EntityManager / Repository / providers).
- ▪️ 🧩 Core first if you care about NoSQL portability; Extended when you need relational power.
- ▪️ 👀 If you build apps spanning SQL + NoSQL, this is worth tracking closely (1.0 is still under development).
#JakartaEE #JakartaQuery #JakartaData #JakartaPersistence #JakartaNoSQL #Java #JPA #NoSQL #CloudNativeJava #OpenSource
Go further with Java certification:
Java👇
Spring👇
SpringBook👇
JavaBook👇