When planning for Jakarta EE 11 began, contributors made it a priority to modernize enterprise Java development by offering a cleaner, more developer-friendly experience. One of its most talked-about additions, Jakarta Data, does that by providing a unified, annotation-driven and intuitive way to handle database operations.
Alfonso Altamirano, Senior Software Engineer at Payara, and Steve Butler, Product Manager at Payara, look at what Jakarta Data offers and how it can change enterprise Java software development activities.
Jakarta EE 11 extends the modernization that began with Jakarta EE 10. It introduces new APIs, performance improvements and clearer development models. Jakarta Data stands at the center of these updates, addressing one of the most pressing issues for developers: the interaction with databases.
Data access has always been a central pillar of enterprise software, and its importance has only grown over the years, due to the digital transformation of businesses. In effect, virtually every application relies on seamless, efficient and secure interactions with its database(s). Such activities, though, have typically been complex, requiring developers to write extensive boilerplate code.
Jakarta Data introduces a new, simplified way for developers to interact with data sources in Jakarta EE applications by standardizing repository patterns and addressing the complexities of data persistence, which can cause latency, maintenance risk and scalability limits if poorly designed.
Rather than navigating multiple layers and patterns, developers now only need to define a single interface. The latest Jakarta specification does this through a number of features, such as a purpose-built query language (Jakarta Data Query Language, JDQL) and built-in supertypes.
The Opportunities offered by Jakarta Data
Prior to Jakarta Data, developers had to define the Data Access Object (DAO) pattern to define multiple classes and components to interact with the data. In addition, they had to interact with JPA Criteria API scripting to create queries. As a result, it was necessary to set up multiple classes to support CRUD (Create, Read, Update, Delete) operations.
This can now be combined into one. The single-point abstraction offered by Jakarta Data, built atop the Jakarta Contexts and Dependency Injection (CDI) API and enhanced with new annotations, is handled at runtime. As a result, it is possible to reduce boilerplate, improve code clarity and simplify code maintenance. These results ultimately make application generation, adaptation and implementation more flexible as well as efficient.
Additional, perhaps less well-known, benefits of Jakarta Data can be experienced when dealing with pagination operations, which used to demand custom logic. Now, they are natively supported, thus making it easier for developers to serve large datasets in applications. In addition, JDQL’s simplified query notation facilitates and expedites interaction with queries without the ceremony required with Jakarta Persistence (JPA) and its Jakarta Persistence Query Language (JPQL).
As effective database handling is crucial in enterprise systems, Jakarta Data’s features support virtually any application involving databases. . Preliminary estimates indicate that the specification can reduce the lines of code dedicated to persistence in projects that have one-to-one relationships with tables by 30-80%, corresponding to hundreds of lines of code.
How Payara Implemented Jakarta Data
Committed to delivering the benefits of Jakarta Data and Jakarta EE 11 to its users, Payara developed its own, independent Jakarta Data implementation rather than relying on third-party solutions. The engineering team began by dividing the requirements and necessary sequence to support the specification. Based on these points, the specialists created smaller, isolated components following a modular approach.
Cross-team collaboration was key to completing the implementation as well as passing the Jakarta Data Technology Compatibility Kit (TCK), as it helped drive simultaneous progress across specification areas. As a result, Payara was able to quickly achieve certification across all three Jakarta EE 11 profiles (Core, Platform, Web) with Payara Platform Community 7 Beta.
While the application server is now officially compatible with Jakarta EE 11 and users can leverage the open-source solution to begin exploring Jakarta Data and its capabilities, Payara is continuing to improve its support for the specification. For example, the team is working on merging the JDQL interpretation and query name creation parsers.
These advances will help developers benefit from an ever more refined, effective and easy to use technology. The result is a continuously evolving runtime that simplifies persistence, enforces consistency and proves that Jakarta EE remains a viable, evolving platform for data-centric application development.
