Unlocking Data Access Excellence with Jakarta Data
summary
Jakarta Data presents a repository-first API that lets domain interfaces like Garage.save or findByType compile down to either JPA/JDBC for relational stores or JSON/doc providers for NoSQL, so the same domain-centric code runs against both worlds. The spec explicitly targets the impedance mismatch by adding generated queries (examples: findByName / findByType auto-query derivation), maps to existing stacks (JPA, JDBC, Quarkus Panache-ish providers) and aims to replace ad hoc DAO/Mapper layers with a consistent, provider-pluggable persistence surface.
AI-written summary · about
chapters (11)
- 0:00Jakarta Data session
- 0:46Persistence layer in Java
- 2:56Modern apps need data storage
- 5:07Database flavors and maturity
- 7:19Persistence layer complexity
- 9:13Persistence in architecture
- 12:05Polyglot persistence
- 13:52Apps versus databases mismatch
- 17:27Data integration patterns
- 23:19Jakarta Data simplifies persistence
- 25:32Summary and resources
related talks
49mUnlocking Data Access Excellence with Jakarta Data
45mJakarta Data - Standardized Data Access for SQL and NoSQL Databases
43mMake your life easier with Jakarta's new persistence features: Data and NoSQL
50mJakarta Data and Jakarta Persistence
50mJakarta Data and Jakarta Persistence
48mManaging Data in Jakarta EE Applications
53mSimplifying NoSQL Database Integration with Jakarta NoSQL
47mJakarta EE 12 and the future of Java persistence