Making Your Life Easier Around Data With Java and Jakarta EE

There is no doubt about the importance of data around the application. We often talk about a stateless application, and it is the data where we delegate the state of the application. If the architecture is the mind, the information is the heart.

This article will cover more about the next steps of Jakarta EE around the world of data and its techniques to work as more besides just the data source. In other words, this is about how to apply practices around data such as repository and CQRS agnostically.

We have JPA for a while in the specification world to make your life easier in the relational database world. We're glad to work on a specification to make it easier to work with NoSQL: Jakarta NoSQL.

The core principle of the Jakarta NoSQL is to standardize behavior, to make a low cognitive load while changing among databases, and at the same time be extensible enough to allow specific behavior from a particular vendor. At this time we have the pleasure of announcing a new version, Jakarta NoSQL Version 1.0.0-b4.

Jakarta NoSQL Version 1.0.0-b4

This version has several library updates, bug fixes, and two new features. A builder pattern is included to create and combine conditions in the query to highlight one. Thus, Jakarta NoSQL has two approaches to creating a database request: using a fluent API and using a builder pattern. We won't cover the difference between that pattern here, but you can go further in my article entitled "Fluent-API: Creating Easier, More Intuitive Code With a Fluent API.".

To demonstrate this resource, we'll create a Worker entity where this Worker will have five attributes: id, name, city, age, and gender. We'll use MongoDB as a data source.

The first step is to have a MongoDB database running. You can make it easy with Docker by running the following command:

docker run -d --name mongodb-instance -p 27017:27017 mongo

The next step is to create a simple Java SE project where we'll include the minimum requirements for running the applications CDI, JSONB, and Eclipse Microprofile Configurations.

Furthermore, we'll include JNoSQL, the Jakarta NoSQL reference implementation. One thing new on this release is the mongodb-extension, where you can explore more particular behavior of this NoSQL vendor.

 <dependency>
    <groupId>org.eclipse.jnosql.mapping</groupId>
    <artifactId>mongodb-extension</artifactId>
    <version>${project.version}</version>
</dependency>

For the application connection with the database, Jakarta NoSQL depends on Eclipse MicroProfile Configuration to explore more of the twelve factors, principally the configuration one.

We'll inject and make it available for CDI.

@ApplicationScoped
public class MongoDBProducer {


    @Inject
    @ConfigProperty(name = "document")
    private DocumentCollectionManager manager;

    @Produces
    public MongoDBDocumentCollectionManager getManager() {
        return (MongoDBDocumentCollectionManager) manager;
    }

    public void destroy(@Disposes DocumentCollectionManager manager) {
        manager.close();
    }

}

We'll create the MongoDB connection. Without a password and user, the advantage of an overwritable configuration is that we can put several properties on production that do not make sense to run locally.

document=document
document.database=olympus
document.settings.jakarta.nosql.host=localhost:27017
document.provider=org.eclipse.jnosql.communication.mongodb.document.MongoDBDocumentConfiguration

We have the project setup; then, we'll move the entity model with the Worker entity. Here, we can see the similarity with JPA. The specification tries to have resemblances, when possible, to have an accessible entrance for the Java developer.

@Entity
public class Worker {

    @Id
    @Convert(ObjectIdConverter.class)
    private String id;

    @Column
    private String name;

    @Column
    private String city;

    @Column
    private int age;

    @Column
    private int dailyHours;

    @Column
    private Gender gender;
   
   //…
}

The next step is to create a specific query, where we'll combine boolean conditions, such as to give workers: 

• I want to return a female older than thirty or a male more than thirty-five.

public class App10 {

    public static void main(String[] args) {
        try (SeContainer container = SeContainerInitializer.newInstance().initialize()) {

           Worker poliana = Worker.builder()
                   .age(30).name("Poliana")
                   .city("Salvador")
                   .gender(Gender.FEMALE)
                   .dailyHours(30).build();

            Worker otavio = Worker.builder()
                    .age(35).name("Otavio")
                    .city("Salvador")
                    .gender(Gender.MALE)
                    .dailyHours(30).build();

            DocumentTemplate template = container.select(DocumentTemplate.class).get();

            template.insert(Arrays.asList(otavio, poliana));

            DocumentCondition maleAfterThirty = and(eq("gender", Gender.MALE),
                    gte("age", 30));

            DocumentCondition femaleAfterThirty = and(eq("gender", Gender.FEMALE),
                    gte("age", 30));

            final DocumentQuery query =  DocumentQuery.builder()
                    .from("Worker")
                    .sort(asc("name"))
                    .where(or(maleAfterThirty, femaleAfterThirty))
                    .build();

            Stream<Worker> stream = template.select(query);
            List<Worker> workers = stream.collect(Collectors.toList());
            workers.forEach(System.out::println);

            template.delete(Worker.class, otavio.getId());
            template.delete(Worker.class, poliana.getId());
        }
    }

After several discussions to have more integration between JPA and NoSQL, the community has decided to create a new specification to apply those patterns around data: Jakarta Data.  We've published it to the Jakarta EE Committee. If you want to know more about it, please read my article entitled "Learn to Access Java Database With Jakarta Data."

When Will There Be a Final Version?

We're waiting for the new Jakarta Specification configuration. The proposal is to replace what we're using with MicroProfile Configuration and, hopefully, create compatibility with both. Until then, we don't have any other option than to wait.

Conclusion

Jakarta NoSQL is helping to engage the Java community. It is creating several discussions, such as the Jakarta Data specification, focusing on how critical it is to handle data, and starting several talks to make the Java Developer's life easier.