Draft:Jakarta Data

• Comment: In accordance with the Wikimedia Foundation's Terms of Use, I disclose that I have been paid by my employer for my contributions to this article. Excentrickristy (talk) 17:08, 8 July 2025 (UTC)

---

Jakarta Data is a specification for data access APIs under the Jakarta EE platform. It enables Java developers to focus on an application's data model by providing an abstraction of the underlying persistence mechanism. By design, Jakarta Data addresses the challenge of integrating multiple and diverse data sources by offering a common and consistent approach to data operations.

Jakarta Data combines a persistent agnostic API with domain-driven design. This allows developers to work with different databases and storage technologies while building an application's data model and workflows around a specific business domain. For example, if an application manages employee recruitment, it may include domain-specific data entities for "candidates" and "hiring managers" and query methods for "get resume" and "add employee" that operate on a MySQL database. If the database technology changes, the entities and methods would require minimal changes to continue operations.

History

The first version of Jakarta Data, known as Jakarta Data 1.0, was released as part of Jakarta EE 11 on June 10, 2024. This release followed the conclusion of the Specification Committee Ballot on June 6, 2024, with representatives from Fujitsu, IBM, Oracle, and other organizations.

The next version of Jakarta Data, 1.1, is currently under development. It is planned for release under Jakarta EE 12.

Objectives

Jakarta Data's core objectives focus on creating a flexible and consistent data access programming model familiar to Jakarta developers. A key objective is persistence agnosticism: Jakarta Data is not tied to any specific database or data source, giving developers the flexibility to choose the most suitable technology for their applications. This allows for easy adaptation to different data solutions as the application or system evolves.

The specification emphasizes a domain-centric approach, aligning data access strategies with the application's core domain logic. This fosters a more cohesive and intuitive development experience, as data manipulation closely mirrors the application's business logic.

Below are other Jakarta Data objectives:

• A unified API that simplifies interaction with different data sources, allowing developers to focus on functionality rather than managing the technical details of different database technologies.
• Pluggable and extensible APIs that support the customization of the framework's behavior when the built-in features do not meet specific needs, enabling a wider range of use cases.
• Simple querying and database operations through domain-centric capabilities, making it easier to work with various persistence engines while aligning with the application's domain model.
• Seamless integration between Java applications and their persistence layers, reducing the need for complex customization for different databases and storage technologies.

Features

The Jakarta Data specification includes several architectural and functional features that define how data is modelled, accessed, and maintained.

Repositories

Jakarta Data follows the Repository design pattern to decouple data storage from the data model, providing a clean, organized way for developers to interact with data sources. They act as mediators between the application's domain logic and its underlying data storage, whether a relational database, NoSQL store, or other persistence layer.

Repositories are defined as Java interfaces and annotated with @Repository. They provide a structured approach to data access, including create, read, update and delete (CRUD) operations.

Developers implement repositories in one of two ways:

• Predefined repository interfaces, known as built-in supertypes, from which user-defined repositories are inherited. The root of this hierarchy is the DataRepository interface, which provides essential CRUD operations and can be extended by application-specific repositories.
• Repositories without built-in supertypes provide greater flexibility by allowing developers to fully control the operations exposed by a repository. This approach is ideal for applications where custom behavior or naming conventions are required.

Queries

Jakarta Data supports parameter-based automatic queries and annotated query methods. The parameter-based querying approach uses methods like @Find and @Delete that generate queries based on the method's parameters. This offers a quick and convenient way to handle simple queries without needing custom query logic.

For more complex queries, Jakarta Data supports annotated query methods using @Query and the Jakarta Data Query Language (JDQL), a subset of the Jakarta Persistence Query Language (JPQL). This approach gives developers full control over query construction, enabling them to write sophisticated, domain-specific queries when needed.

Entity Classes

Entity classes are the fundamental building blocks for constructing a data model. An entity represents a schema for data, which can range from a simple tuple of types in relational databases to more complex structures found in document or key-value stores. Entity classes define the structure and properties of the data being represented and are tied to a repository, which provides the methods for retrieving and storing instances of the entity in the data store.

An entity class contains fields or accessor methods corresponding to the properties of the entity. Each entity class is annotated to indicate that it represents a persistent data type, which is stored and retrieved from a data store. The data schema associated with an entity class defines the structure of the data it represents.

In cases where the data store requires an explicit schema, such as with relational databases, the schema is typically defined using SQL Data Definition Language (DDL) statements. For other types of data stores, like key-value or document-based stores, the schema may be implicit.

Pagination

Jakarta Data offers two types of pagination to accommodate different use cases:

• Offset-based pagination: data is divided into pages of a fixed size, and applications retrieve records based on their position relative to the first record. This method is commonly used when dealing with static datasets where the data does not change frequently between page requests.
• Cursor-based pagination (also known as seek or keyset pagination): applications navigate through a dataset by using a unique key or combination of values relative to the current position. This method reduces the performance impact of scanning earlier pages of results and helps prevent data synchronization issues when data changes between page requests.

Jakarta Data Providers

Jakarta Data Providers are implementations of application-defined repositories that act as a mediator between domain logic and the underlying data sources. These providers can either be integrated components within a Jakarta EE container or separate components that integrate with the container using standard or proprietary service provider interfaces (SPI).

Code Sample

@Repository
public interface CarRepository extends BasicRepository<Car, Long> {

  List<Car> findByType(CarType type);

  Optional<Car> findByName(String name);

}

See also

• Jakarta EE
• Domain-driven design

Reception

Jakarta Data 1.0 received attention from independent technology publications following its release as part of Jakarta EE 11 in June 2024.

An article in InfoQ described Jakarta Data as a significant step forward for simplifying persistence integration within Jakarta EE applications, highlighting its repository-based programming model and support for polyglot persistence.

InfoWorld reported that the Eclipse Foundation's Jakarta EE 11 release included Jakarta Data as its only new specification, noting that it standardized the repository pattern for data access and aimed to offer familiar patterns for developers.

ADTmag also covered the Jakarta EE 11 release, describing Jakarta Data as enabling flexible pagination strategies and annotated query support for CRUD operations.

A separate InfoQ feature on persistence architectures compared Jakarta Data to similar frameworks such as Spring Data and Micronaut Data, noting its domain-centric design and flexibility in working with various database technologies.

External links

• Jakarta Data Specification Official Website
  • Jakarta Data 1.0 Specification Document
• Jakarta Data on Github
• Jakarta Data Video Guide on YouTube