Jakarta EE 12 Milestone 2: Advent of the Data Age Along with Consistency and Configuration

After the release of Jakarta EE 11 in June 2025, work on Jakarta EE 12 had been well underway, a release poised to deliver improved integrations and alignment with its predecessor.

The second of four milestone releases of Jakarta EE 12 is scheduled for the first quarter of 2026. In this article, we will discuss new features and capabilities that will provide consistency and configuration, improving the Jakarta EE developer experience. Furthermore, we will highlight some initial projects found in the platform.

Why This Release Matters for Developers and Architects

When we talk about the Java platform itself, Jakarta EE 12 Milestone 2 reshapes the platform and directly impacts the Java ecosystem, not just individual specifications.

Jakarta EE 12 brings a new perspective on data by treating querying, data access, configuration, and consistency as first-class platform concerns. As such, the theme for Jakarta EE 12 is Robust and Flexible.

Jakarta EE is the foundation for Java frameworks such as Quarkus and Spring. For developers, this development translates into clearer APIs, less duplication across layers, and concepts that feel familiar regardless of the framework being used.

For architects, Jakarta EE (formerly Java EE) has always provided stability and portability, but Jakarta EE 12 adds architectural relevance.

The platform now explicitly supports polyglot persistence, modern Java baselines, and emerging concerns such as agent-based AI integration, without forcing frameworks into unnatural abstractions. This approach creates a more adaptive architecture and, furthermore, polyglot persistence, allowing an architect to choose the right database for the right scenario.

Understanding the Jakarta EE 12 Release Process

Before diving into what is new in Jakarta EE 12 Milestone 2, it is important to briefly explain the development stages, including testing, community feedback, and two milestones for revisions. As is typical in any software development process, those specifications are subject to change or delay until the final vote (in this case by the Jakarta EE Steering Committee on the process). As shown in Figure 1, this is the current set of specifications that are part of the Jakarta EE 12 Platform:

Figure 1: The specifications in the Jakarta EE Platform

It is important to note that the Jakarta MVC 3.1 and Jakarta NoSQL 1.1 specifications are currently under consideration for inclusion in the Jakarta EE 12 Platform.

In Jakarta EE 11, we saw an impact with Java 17 as the baseline with support for Java 21. This inclusion allowed you to use Java records as embedded classes and as IDs in the Jakarta Persistence specification and virtual threads in the Jakarta Concurrency specification. For Jakarta EE 12, the baseline will be Java 21 with support for Java 25. At a platform level, this release reflects the definitive move away from the deprecated SecurityManager, a broader cleanup of legacy APIs and ambiguous specification language, and preparation for modern web protocols such as HTTP/3.

Due to the sunsetting of OSSRH and the subsequent new staging protocol for Maven Central, some of the specifications were not able to provide a Milestone 1 release. Therefore, those specifications will directly move forward to Milestone 2 as shown in this dashboard.

We will focus on four specifications that could provide a Milestone 2 release:

• Jakarta Query has a common object-oriented language for the persistence layer.
• Jakarta Data supports dynamic queries on repositories and integration with Jakarta Query.
• Jakarta Persistence supports the SequencedCollection interface, introduced in Java 21, and integration with Jakarta Query.
• Jakarta NoSQL introduces projections with Java records and an integration with Jakarta Query.

Along with the new Robust and Flexible theme, we could refer to Jakarta EE 12 as the Data Age that includes polyglot persistence within the Jakarta EE ecosystem to enable Jakarta EE to “speak” both SQL and NoSQL, with the possible inclusion of Jakarta NoSQL 1.1.

Jakarta Query

As the new specification approved for inclusion in the Jakarta EE 12 Platform and Web Profile, Jakarta Query 1.0, the initial release, provides a Java query language for the persistence layer. The goal is to extract the Jakarta Persistence Query Language (JPQL) from Jakarta Persistence and the Jakarta Data Query Language (JDQL) from Jakarta Data and centralize it into a single specification that is based on two languages:

• Jakarta Common Query Language (JCQL), the basic language where you can perform basic query operations that can be used with both the Jakarta Data and Jakarta NoSQL specifications.
• Jakarta Persistence Query Language (JPQL), a language that extends the Core Language with relational and entity features for the Jakarta Persistence specification and other SQL-based technologies.

Since this is a new specification, we are still working on several points that require improvement, including the terminology used in the specification and its components. What we have is a specification to define a language that consists of two profiles or languages.

The Core Language is a subset of the full Jakarta Query language, focusing on portable operations such as selection, restriction, ordering, and simple projection. To illustrate, consider the following JSON representation of a Room document:

{
 "id": "R-101",
 "type": "DELUXE",
 "status": "AVAILABLE",
 "number": 42
}

Using the Core Language, a query might retrieve all deluxe rooms that are available, ordered by their number:

FROM Room WHERE type="DELUXE" AND status="AVAILABLE" ORDER BY number

The Persistence Language is the relational query language that introduces SQL-oriented constructs such as joins, grouping, and bulk updates or deletes. These are especially useful in relational contexts. For example, imagine a Hotel document with an embedded list of rooms.

With the Persistence Language, a query could count the number of occupied rooms per hotel, returning only those with more than ten:

SELECT h.name, count(r) FROM Hotel h JOIN h.rooms r WHERE r.status="OCCUPIED" GROUP BY h.name HAVING count(r) > 10 ORDER BY count(r) DESC

The primary goal of this specification is to serve as the reference language for persistence. Therefore, it will be utilized in Jakarta NoSQL, Jakarta Persistence, and Jakarta Data.

Jakarta Data

Jakarta Data 1.0 was the popular new specification in Jakarta EE 11. Jakarta Data 1.1, the latest version of this specification, simplifies the integration between Java and the persistence layer, allowing you to use both NoSQL and relational databases through a unified interface. Three new features are introduced in this new version.

The first feature allows you to execute dynamic queries within the repository. You can create a search by using a fluent API to achieve the search, given the Restriction attribute that you can include in the repository.

@Repository
public interface Products {
List findAll(Restriction restriction);
}

This version includes more capabilities on the metamodel, including the fluent API capability to search. Thus, we can combine restrictions in the repository:

@Inject
private Products products;

List found = products.findAll(
   Restrict.all(
       _Product.type.equalTo(ProductType.PHYSICAL),
       _Product.price.greaterThan(10.00f),
       _Product.name.contains("Jakarta")
   )
);

The second feature is an improved search using the @Is annotation. In Jakarta Data 1.0, there was the option to query by an equals condition. But in this new version, you can either use the @Is annotation or use an instance of the new Constraint interface:

List pricedBelow(@By(_Product.PRICE) @Is(LessThan.class) float max);

@Find
Page search(@By(_Product.NAME) @s(Like.class) String pattern,
                        PageRequest pagination,
                         Order; order);

@Find    
List inSomeOtherRegionThan( @By(_Country.REGION) NotEqualTo exclude);

Jakarta Query will replace the now-deprecated JDQL in Jakarta Data with the Core Language. The goal is to maintain compatibility so there is no impact on the users in Jakarta EE 12.

@Repository
public interface BookRepository extends BasicRepository {

 // Find books with titles matching a specific pattern
 @Query("WHERE title LIKE :titlePattern")
 List booksMatchingTitle(String titlePattern);

 // Select books by a specific author and sort them by title
 @Query("WHERE author.name = :author ORDER BY title")
 List findByAuthorSortedByTitle(String author);
}

Jakarta Data started out with stateless repositories by default. In this approach, every operation is handled one at a time, with no context or memory carried over between calls, keeping things simple, predictable, and makes it clear where each transaction begins and ends.

With the latest version, Jakarta Data now also supports stateful repositories. With this support, you can use a persistence context, just like in the Jakarta Persistence specification. Stateful repositories let you manage the full lifecycle of your entities, like saving, updating, refreshing, detaching, and deleting. You can also take advantage of features such as deferred synchronization and lazy loading.

@Repository
public interface Products extends DataRepository {
   @Persist
   void add(Product product);
   @Merge
   Product merge(Product product);
   @Remove
   void remove(Product product);
   @Refresh
   void reload(Product product);
   @Detach
   void detach(Product product);
}

Jakarta NoSQL

Jakarta NoSQL 1.1, the latest version of this specification, facilitates easy integration of NoSQL and Java in enterprise Java. A highlight of this release is to support a query language via the Core Language feature of Jakarta Query. This release will be driven by a similar terminology to that of Jakarta Persistence, making it easier for Java developers to work with NoSQL databases in enterprise applications.

Jakarta NoSQL provides two features. The first is the new Query interface, which provides a structure similar to that of its already existing counterpart defined in Jakarta Persistence. This interface will serve as the bridge between the Core Language and the Jakarta NoSQL specification. The Query interface allows you to dynamically set parameters and return a single result as a List, Stream, or Optional.

List cars = template.query("FROM Car WHERE type = :type")
                        .bind("type", CarType.SPORT)
                        .result();

The new TypedQuery interface allows you to either define the entity in the query and return it as the entity itself or to return it as a new structure as a projection defined by a record class.

@Projection(from = Car.class)
public record BudgetCar(String name, double price) {}

List cheapCars = template
   .typedQuery("WHERE price < 100", BudgetCar.class)
   .result();

Jakarta Persistence

One of the new features in Jakarta Persistence 4.0, the latest version of this specification, is the transfer of the JPQL into Jakarta Query. Jakarta Persistence is the data-oriented specification that will still utilize JPQL as it did with Jakarta Data. This language will maintain backward compatibility. Thus, it won’t impact Java developers who may still be using previous versions of JPQL.

Jakarta Persistence also supports Java 21 to provide support to the new structures:

@Entity
@Table(name = "orders")
public class Order {
   @Id
   @GeneratedValue(strategy = GenerationType.UUID)
   private UUID id;
   @Column(nullable = false)
   private String customer;
   @Column(nullable = false)
   private Instant createdAt = Instant.now();
   @ElementCollection
   @CollectionTable(name = "order_lines",
                    joinColumns = @JoinColumn(name = "order_id"))
   @Column(name = "item")
   private SequencedCollection items = new LinkedHashSet<>();
}

There are discussions about adding annotations for static queries in Jakarta Data. The goal is to provide more capabilities and options for running queries that combine Jakarta Data and Jakarta Persistence.

@Repository
interface Library {
    @StaticQuery("where title like :pattern")
    @ReadQueryOptions(cacheStoreMode=BYPASS)
    List books(String pattern);
}

You can learn more about Jakarta Persistence 4.0 at this blog post by Gavin King, Red Hat Senior Distinguished Engineer at IBM.

Jakarta Agentic Artificial Intelligence

In early November 2025, a new specification focused on the adoption of AI passed its creation review. The Jakarta Agentic AI specification provides a set of vendor-neutral APIs designed to simplify, standardize, and streamline the process of building, deploying, and operating AI agents on Jakarta EE runtimes.

By offering a unified approach, developers can create intelligent solutions with greater efficiency and consistency across diverse environments.

These APIs will be designed to promote interoperability and reliability, enabling organizations to accelerate innovation while maintaining flexibility and alignment with industry best practices.

The scope of this new specification includes:

• Establish standardized use patterns and life cycles for AI agents operating within Jakarta EE runtimes that promotes interoperability and consistency across implementations.
• Offer a streamlined facade for accessing foundational AI capabilities, such as large language models (LLMs), without standardising the LLMs themselves. The API provides straightforward, pluggable, and configurable integration with existing LLM APIs like LangChain4j and Spring AI, analogous to how Jakarta Persistence unwraps access to underlying non-standard APIs.
• The API is expected to include a fluent Java API for defining agent workflows, rather than XML. These workflows will be dynamic at runtime, containing flexible adaptation rather than relying on static definitions at deployment time. Additionally, there may be support for pluggability via formats such as YAML and XML.
• Establish integrations with essential Jakarta EE specifications. These initegrations include Jakarta Validation, Jakarta RESTful Web Services, Jakarta JSON Binding, Jakarta Persistence, Jakarta Data, Jakarta Transactions, Jakarta NoSQL, Jakarta Concurrency, Jakarta Security, and Jakarta Messaging.
• The project leverages Jakarta Config where feasible and permits implementations to use MicroProfile Config.
• Implementations may also offer integrations with OpenTelemetry for enhanced observability.

Jakarta Agentic AI 1.0, the initial release, intentionally minimal, catalyses early adoption, fosters community engagement, and raises awareness of the Jakarta Agentic AI initiative. Future enhancements will be guided by industry trends and continuous user and contributor feedback, so that the specification remains relevant and forward-looking.

This release centers on foundational programming models and best practices, and introduces a lightweight facade for integrating LLMs. Subsequent versions are expected to expand on programmatic life cycle management and provide comprehensive workflow APIs for more advanced agent orchestration.

The specification is under development, so you can contribute to the final stage by participating in the specification process and providing feedback and reporting bugs via the email list or directly in the GitHub repository for each specification. If you want to contribute directly to the code, but you don’t know how to do it, there is the Jakarta EE Community Mentorship program, where you can learn how to contribute directly to the code at the Java enterprise platform.

Jakarta EE 12 Adoption Timeline

As with any software development process, a milestone release is not intended to be used within production code; rather, it allows developers to experiment, test, and provide feedback. The goal of milestone releases is similar to that of incubation and preview features in OpenJDK.

Jakarta EE 12 delivers on its main promise by maintaining backward compatibility, benefiting organizations that already use Jakarta Persistence and Jakarta Data. Recent refinements, including unified query languages and clearer boundaries between stateful and stateless repository models, will provide permanent solutions to eliminate all areas of uncertainty. The changes focus on increasing transparency by making visible cases of odd behavior found in old code. The current phase requires architects and developers to stop solving urgent problems so they can learn how new definitions will change their existing work methods.

For the adoption of Jakarta EE 12 to become widespread, tooling will be a decisive factor, especially for Jakarta Query and repository-based data access. The current stage of development still requires additional work to complete features such as IDE integration, query validation, refactoring, and runtime diagnostics. The tooling ecosystem will reach its full capabilities when the implementations are finalized.

Conclusion

Jakarta EE 12 Milestone 2 defines the first step towards the newest version of the enterprise Java platform. Opportunities provided through the open and transparent contribution process allow the entire community to provide feedback on the specifications. The introduction of Jakarta Query consolidates decades of query evolution, from JPQL to JDQL, into a single, extensible language that bridges the worlds of relational and non-relational databases. Jakarta Data, Jakarta Persistence, and Jakarta NoSQL now share a consistent query foundation that can reduce fragmentation and improve developer experience across the ecosystem.

Using Java 21 as the new baseline, Jakarta EE continues its tradition of embracing modern Java language features, providing improved performance, cleaner syntax, and long-term maintainability. While this milestone marks the beginning of the Jakarta EE 12 journey, it already indicates a clear direction: tighter integration among specifications, improved developer productivity, and even stronger alignment with the core Java platform.

The third and fourth milestones will refine ideas, stabilize APIs, and increase compatibility.