iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Jakarta Query 1.0-M2 is a draft effort to give Jakarta EE data technologies a shared, object-oriented query language—not a finalized replacement for JPQL. Its goal is to make query capabilities more consistent across Jakarta Persistence, Jakarta Data, and Jakarta NoSQL. The M2 document is dated May 25, 2026, and the Jakarta EE specification catalog lists Jakarta Query as under development, so treat its grammar, APIs, and compatibility as provisional.
What Jakarta Query is intended to do
Jakarta Query addresses a practical divide: Jakarta EE applications may access relational databases and other kinds of stores through different specifications, each with its own query APIs and assumptions. The Jakarta Query effort proposes a shared query model and vocabulary for those specifications, with common and relational levels. The intent is to improve consistency across data technologies without making every datastore behave like a relational database.
That is a direction for the specifications to build on, not evidence that every query can run unchanged against every backend. Portability will depend on which parts of the language are common, what a provider supports, and how a particular store represents and returns data.
How Jakarta Query relates to Persistence, Data, and NoSQL
| Technology | Role in the query picture |
|---|---|
| Jakarta Query | Draft shared query foundation, described with common and relational levels. |
| Jakarta Persistence | Defines entity persistence and JPQL, its string-based query language for entity and persistent state. |
| Jakarta Data | Documents Jakarta Common Query Language (JCQL) for select, update, and delete operations over relational and non-relational data. |
| Jakarta NoSQL | Provides a unified API for multiple datastore types and documents string-based queries, including JCQL for typed and generic query operations. |
Jakarta Persistence and JPQL
Jakarta Persistence describes its query language this way: “The Jakarta Persistence query language is a query specification language for string-based dynamic queries and static queries expressed through metadata.” JPQL queries entity and persistent-state concepts; a provider can compile them to SQL or another target language. That persistence-specific role remains distinct from the broader aim of sharing query concepts across data specifications.
#1 Best Overall
Jakarta Persistence 3.2 already adds query-language features including union, intersect, except, cast, left, right, and replace, along with Criteria API and result-handling enhancements. These are 3.2 changes, not proof that Jakarta Query M2 has replaced or removed JPQL.
Jakarta Data and JCQL
Jakarta Data documentation identifies Jakarta Common Query Language (JCQL) as a language defined by Jakarta Query for relational and non-relational data. Its documented statement families are select, update, and delete. A repository method can use @Query with JCQL; for example, a query condition can be written as WHERE title LIKE :title ORDER BY title ASC, id ASC.
Rank #2
This gives repository-oriented applications a way to express a query without embedding a datastore-specific query string in every method. The actual behavior still depends on the repository implementation and the capabilities of the target datastore.
Jakarta NoSQL and different datastore models
Jakarta NoSQL covers document, key-value, column-oriented, graph, and emerging data stores through a unified API. Its documentation includes string-query APIs and identifies JCQL as the query format for typed and generic query operations. This is a concrete example of the unification goal: a common query format can sit across APIs for stores whose underlying data models differ substantially.
Common syntax does not, by itself, guarantee identical semantics or supported operations across those stores. When evaluating portability, check the target provider’s supported grammar, result mapping, and datastore-specific behavior.
Does Jakarta Query replace JPQL?
No replacement is established by the M2 material described here. JPQL remains the query language specified by Jakarta Persistence for entity-oriented queries. Jakarta Query is best understood as a shared foundation and vocabulary intended to connect data specifications, while Jakarta Persistence continues to define persistence and JPQL behavior.
A final compatibility decision would need to come from the completed specification and its implementation guidance. Until then, do not assume JPQL code must be rewritten, that Jakarta Query is a drop-in substitute, or that the two languages have identical semantics.
Recommended Free Tools
What changed in Jakarta EE 12 M2?
The M2 milestone makes the draft Jakarta Query specification available as part of the Jakarta EE 12-era unification effort. The available information establishes its draft status and intended relationship to Persistence, Data, and NoSQL; it does not establish a reliable, itemized change list from an earlier Jakarta Query milestone. It would therefore be misleading to present a specific grammar or API change as “new in M2” without a documented before-and-after comparison.
Best Value
One relevant platform planning detail is that Jakarta EE 12 places Jakarta Persistence on a 3.2-to-4.0 update path. A platform plan is not a guarantee that every planned version or integration detail has been finalized. Check the final platform and individual specification versions before making a version-specific implementation decision.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Can you use Jakarta Query in production?
The M2 document is explicitly marked Draft, and the Jakarta EE catalog lists Jakarta Query as under development. That is not a basis for treating its APIs or grammar as stable production contracts. No authoritative adoption, performance, provider-count, or production-deployment statistics are established in the material available for this topic.
For a production project, use the finalized Jakarta EE and specification versions supported by your chosen implementation. If you experiment with draft Jakarta Query material, isolate it from compatibility-critical code and verify the provider’s supported features, mapping and projection rules, transaction and persistence-context behavior, and test coverage. Reassess the integration against the final specification before depending on it.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
