Moving Jakarta Forward: Jakarta NoSQL Approved as an EE4J Project

Java Enterprise Edition (Java EE) is an umbrella with specifications and APIs to enterprise features such as distributed computing and web services. It is running on reference runtimes that can be microservices or application servers, which handle transactions, security, scalability, concurrency, and management of the components it is deploying. It has been using widely in Java applications — even if you are a Spring developer, you are using Java EE. Enterprise Java is being standardized under the Eclipse Foundation with the new brand, Jakarta EE. Jakarta EE picks up where Java EE 8 left off, but the roadmap going forward will be focused on modern innovations such as microservices, modularity, and now, NoSQL databases. To move Jakarta EE forward, the first specification did the next step, and it has been approved as EE4J. This post will talk about this new specification and the subsequent actions to make the Jakarta EE community even greater.

This result comes from one year of community work. Thus, there are some posts that explain the top questions about this specification:

• Java and NoSQL
• Why not do it on JPA?
• Modularity strategy on the project
• Oracle effort with NoSQL at Java EE

Wait, wait, wait. Did you say EE4J? What not Jakarta EE? Briefly, from Ivar Grimstad has a post about it:

EE4J

Eclipse Enterprise for Java (EE4J) is the top level project in the Eclipse Foundation for all the projects for creating the standards that will form the base for Jakarta EE. The EE4J Project Management Committee (PMC) is responsible for maintaining the overall vision for the top level project. It will set the standards and requirements for releases and help the projects communicate and cooperate.

Jakarta EE

Jakarta EE is the name of the platform governed by the Jakarta EE Working Group. The first version will be Jakarta EE 8, which will be based on the Java EE 8 technologies transferred from Oracle to the Eclipse Foundation.

As the first specification, that will be an unexplorable world about the process and release cadence, but several articles about the Eclipse process philosophy expects it will faster than the JCP, which it will put on proof at this specification.

As a Java developer, I expect a clean process that is focused and community-driven; therefore, a release cadence every three months so that the community can test and provide feedback until the Jakarta EE 9 version, 1.0.0 that looks like an agile methodology. At JCP, there is a lifecycle such as draft and public review.

The first step in Jakarta NoSQL technically is to make the API. The API will have modularity and it will come from the Eclipse JNoSQL, thus, Jakarta NoSQL is the API and TCK EclipseJNoSQL is the reference implementation to that.

The initial scope project does exist and there is a legal process to move to Eclipse Foundation as Jakarta NoSQL. Basically, it is from Eclipse JNoSQL; with the new package name, now it is "jakarta.nosql." In the code below, it shows how the API communication might be in the future:

import jakarta.nosql.document.DocumentCollectionManager;
import jakarta.nosql.document.DocumentCollectionManagerFactory;
import jakarta.nosql.document.DocumentConfiguration;
import jakarta.nosql.document.DocumentDeleteQuery;
import jakarta.nosql.document.DocumentEntity;
import jakarta.nosql.document.DocumentQuery;

import java.util.Arrays;
import java.util.List;

public class App {

    public static void main(String[] args) {
        //it loads from Service loader
        DocumentConfiguration configuration = DocumentConfiguration.getConfiguration();
        try (DocumentCollectionManagerFactory managerFactory = configuration.get()) {
            final DocumentCollectionManager manager = managerFactory.get("database");
            DocumentEntity entity = DocumentEntity.of("God");
            entity.add("name", "Diana");
            entity.add("age", 10);
            entity.add("versions", Arrays.asList("0.0.1", "0.0.2", "0.0.3"));
            manager.insert(entity);
            List<DocumentEntity> entities = DocumentQuery.select().from("God")
                    .where("name").eq("Diana").execute(manager);

            DocumentDeleteQuery.delete().from("God")
                    .where("age").gte(10).execute(manager);
        }

    }
}

Jakarta NoSQL will use the same approaches of Eclipse JNoSQL; in other words, it will have one API to each NoSQL type (key-value, column, document, graph). At the mapping, it will use the same path with the commons API that will have classes that will be shared to all NoSQL databases, including Mapping annotations such as Entity, Column, Id and so on.

import jakarta.nosql.mapping.Column;
import jakarta.nosql.mapping.Entity;
import jakarta.nosql.mapping.Id;

import java.util.List;

@Entity
public class Person {

    @Id
    private Long id;

    @Column
    private String name;

    @Column
    private List<String> phones;

    //getter and setter
}

import jakarta.nosql.document.DocumentQuery;
import jakarta.nosql.mapping.document.DocumentTemplate;

import javax.enterprise.inject.se.SeContainer;
import javax.enterprise.inject.se.SeContainerInitializer;
import java.util.Arrays;
import java.util.Optional;
import java.util.concurrent.ThreadLocalRandom;

import static jakarta.nosql.document.DocumentQuery.select;

public class App2 {

    public static void main(String[] args) {
        ThreadLocalRandom random = ThreadLocalRandom.current();
        Long id = random.nextLong();
        try (SeContainer container = SeContainerInitializer.newInstance().initialize()) {

            Person person = new Person();
            person.setPhones(Arrays.asList("234", "432"));
            person.setName("Name");
            person.setId(id);
            DocumentTemplate template = container.select(DocumentTemplate.class).get();
            Person saved = template.insert(person);
            System.out.println("Person saved" + saved);

            DocumentQuery query = select().from("Person")
                    .where("_id").eq(id).build();

            Optional<Person> personOptional = template.singleResult(query);
            System.out.println("Entity found: " + personOptional);
        }
    }
}

Jakarta EE has a bright future — it's open source, contains significant integration abilities, and, most importantly, community. More transparency, after all, is the most powerful aspect of Jakarta. It's not the technology itself, but the heart of the community. Therefore, the success is in the hand of each developer. We hope to provide both on the first Jakarta specification.