跳转到主要内容

Jakarta NoSQL 1.0 (under development)

Jakarta NoSQL is a Java API standard that streamlines the integration of Java applications with NoSQL databases. It defines a set of APIs and provides a standard implementation for most NoSQL databases. The goal is to create the specification in Jakarta EE to help Jakarta EE developers create enterprise-grade applications using Java® and NoSQL technologies. It helps them create scalable applications while maintaining low coupling with the underlying NoSQL technology.

In general, we made some progress, especially with the creation of TCKs: https://github.com/eclipse-ee4j/nosql/tree/master/tck All APIs proved to be quite stable, except for the Graph API, and that is why there is no API for graphs. We are waiting for the definition of a standard graphical communication API, either Apache TinkerPop or Open Cypher, led by Neo4J. Therefore, we only have a Graph implementation side, but not in the API, at least for a while. Regarding the migration to Jakarta EE facilities, we already have a Draft PR ready as soon as the new version of Jakarta EE is released:

https://github.com/eclipse-ee4j/nosql/pull/55

A point that we are also studying is the Quarkus and Micronaut effect that uses the Annotation Processor instead of reflection and seeing how to make an API that is possible in both directions.

We’ve removed the Duke references in the spec docs and also in all GitHub repositories. We replaced the “artemis” and “diana” package names and put “mapping” and communication respectively instead.

We could keep the compatibility in all changes in the last three months, which is very good. We are still waiting for the Jakarta Configuration Specification to use instead of Eclipse MicroProfile Configuration.

The JPA e-mail list appears the prospects to create a specification to work with several patterns where the data is agnostic; therefore, this specification will work with NoSQL, Relational, or even Rest Applications.

Next quarter, we’ll work on JPA and NoSQL integration and move the API forward to use Java 11 as a minimum requirement, and upgrade the API to the Jakarta EE 10 as soon it gets a release.

Compatible Implementations

Ballots

Plan Review

The Specification Committee Ballot concluded successfully on 2020-10-12 with the following results.

Representative Representative for: Vote
Kenji Kazumura Fujitsu +1
Dan Bandera, Kevin Sutter IBM 0
Ed Bratt, Dmitry Kornilov Oracle +1
Andrew Pielage, Matt Gill Payara +1
Scott Stark, Mark Little Red Hat 0
David Blevins, Jean-Louis Monteiro Tomitribe +1
Ivar Grimstad EE4J PMC +1
Marcelo Ancelmo, Martijn Verburg Participant Members +1
Werner Keil Committer Members +1
Scott (Congquan) Wang Enterprise Members +1
Total 8

The ballot was run in the jakarta.ee-spec mailing list

返回顶部