This post was written by Otavio Santana, a Brazilian Java Champion and SouJava leader.
Java Enterprise Edition (Java EE) is an umbrella with specifications and APIs for enterprise features such as distributed computing and web services. It is implemented by runtimes that can be micro containers or application servers, which handle transactions, security, scalability, concurrency, and management of the components being deployed to it. It has been used 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 road map going forward will be focused on modern innovations such as microservices, modularity, and now, NoSQL databases. To move Jakarta EE forward, the first new specification finished the next step, and it has been approved as an EE4J project. This post will talk about this new specification and the subsequent actions to make the Jakarta EE community even greater.
This end 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
But wait, did you say EE4J? Why not Jakarta EE? Ivar Grimstad has a post about that.
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 new specification, it will be an unexplored world with the process and release cadence, but the Eclipse process philosophy expects it will be faster than the JCP, which will be proven out with 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 release. I am aiming for a 1.0 release that looks agile. As with the JCP, there is a life-cycle such as draft and public review.
The first step in Jakarta NoSQL technically is to design the API. The API will have modularity and it will come largely from Eclipse JNoSQL. Thus, Jakarta NoSQL will be the API and TCK while Eclipse JNoSQL will be a reference implementation.
The initial project does already exist and there is a legal process to move to the Eclipse Foundation as Jakarta NoSQL. Basically, it is Eclipse JNoSQL, but with a new package name – now it is “jakarta.nosql.” The code below 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 approach as Eclipse JNoSQL. In other words, it will have one API for each NoSQL type (key-value, column, document, graph). The mapping will be done through a common API that will have classes that will be shared across all NoSQL databases, including annotations such as Entity, Column, Id and so on.
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 EE has a bright future — it’s open source, contains significant integration abilities, and, most importantly, a community. More transparency, after all, is the most powerful aspect of Jakarta. It’s not the technology itself, but the heart of the community that matters. Therefore, success is ultimately in the hands of ordinary developers. We hope to provide both the technology and the heart on the first new Jakarta specification.
This post was written by Otavio Santana and first appeared here. Otavio is a speaker, Java Champion, SouJava leader and Duke’s Choice Award winner.
Jakarta EE Ambassadors 