Moving Jakarta Forward – Jakarta NoSQL Approved as an EE4J Project

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:

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.

Image title

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.

Jakarta NoSQL vs JNoSQL

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.

Advertisements

Java EE is Officially Retired. It’s Now Called Jakarta EE. How Did We Get Here?

This post was written by Buhake Sindi, a Java EE Guardian.

The results are out and it’s official: Java EE has been retired. This announcement was made by The Eclipse Foundation’s executive director, Mike Milinkovich on his Life at Eclipse blog.

Almost 7,000 people voted in our community poll, and over 64% voted in favor of Jakarta EE.

 

Goodbye JavaEE, hello Jakarta EE. I was one of the fortunate voters who voted (after a tough thought and decision) on Jakarta EE. Now, I have read responses on Twitter and Reddit that there were only 2 options to choose from (i.e., lack of choice) so let’s have a bit of a history lesson.

How did we get here?

1) The Announcements

On 12 September 2017, David Delabassee announced on the Oracle blog that, along with IBM and RedHat, that:

 

 After careful review, we have selected the Eclipse Foundation as the foundation that we will work with going forward to make the above a reality. The Eclipse Foundation has strong experience and involvement with Java EE and related technologies. This will help us transition Java EE rapidly, create community-friendly processes for evolving the platform, and leverage complementary projects such as MicroProfile. We look forward to this collaboration.

The Eclipse Foundation welcomed the move, and on 29 September 2017, Eclipse Foundation announced a new top-level project called Eclipse Enterprise for Java (EE4J).

2) Brand Name Selection Phase 1: Name suggestions

On 15 November 2017, The Eclipse Foundation reached out to the community and the world to “Help Pick the New Name for Java EE” (The primary reason for the name suggestions was due to the Java name copyright. Oracle owns the name Java and now that the project moved to The Eclipse Foundation, they could not have any projects that started with the word Java). Wayne Beaton (Director of Open Source Projects at The Eclipse Foundation) opened up the GitHub issue and the responses were “awesome” (his word). It was in phase 1 that GitHub user, Kenneth J. Jaegersuggested the name “Jakarta Enterprise Edition”.

3) Brand Name Selection Phase 2: The vote.

On 07 February 2018, the voting was announced for the brand name selection and it began under the EE.next Working group, which is similar to Java Community Process (JCP) with Oracle. The vote ran until the 23 February 2018.

Why Jakarta?

As mentioned on point 2, it was suggested during phase 1 of the name brand selection process. Jakarta (was) an Apache trademark and it has a significant history in contributing to open source Java solutions. Apache Jakarta was retired on 21 December 2011. David Blevins, CEO and Founder of Tomitribepoints out the advantage of the new name Jakarta EE and how Apache Software Foundation have agreed & given the rights to The Eclipse Foundation to use the Jakarta name:

 

 While “Jakarta EE” is not only great because it can be shortened to
“JEE”, referred to simply as “EE” and provides us with a free pass on
any acronyms that have “J” in them, it also has room to grow.
The bare word “Jakarta” would be ours and in the future we could
create other things under this brand if we wanted. This may include
“Jakarta ME”, “Jakarta MicroProfile” or a conference called
“JakartaOne.” All of these names roll off the tongue, are instantly
familiar and most importantly are community owned and free of any
external licensing restrictions.

In Summary

In the words of Mike Milinkovich:

However, as of today, it is preferred that when you are generically referring to this open source software platform that you call it Jakarta EE rather than EE4J. EE4J, the Eclipse Top-level project, is the only name we’ve had for a couple of months, but as we at least tried to make clear, that was never intended to be the brand name.

So, the terms J2EE and Java EE are no longer valid. It’s a hard pill to swallow but the name is here to stay.

 


This post was written by a Java EE Guardian, Buhake Sindi, and first appeared here. Buhake is a DevOps engineer, Java & Jakarta EE Developer, Engineer & Consultant with over 12 years of Development experience. He also participates in teaching programming to children through Devoxx4Kids South Africa.

EE4J: An Opportunity for Reconciliation in the Java Ecosystem?

This post was written by Jean-François James, a Java EE Guardian .

I have a dream: that one day the whole Java community would join forces to strengthen its position on server-side applications where movements such as containerization, microservices, cloud-native or serverless are challenging its paradigms.

As explained in my previous post, Java EE (Enterprise Edition) won’t go beyond version 8 and the future will take a different path under a new name and governance within the Eclipse Enterprise for Java (EE4J) project.

  

I am entering a dangerous territory on a subject which has often been very polemical but I will try to deal with it with as much objectivity as possible. At my own risk and peril…

Java EE and Spring: a complex relationship

In my impact assessment on the actors of the Java EE ecosystem, I have omitted to mention an indirect but very influential one: Pivotal and more precisely its famous Spring framework.

The relationship between Java EE and Spring has always been rich and complex in “best enemies” mode.

Spring was born in 2004, at the initiative of Rod Johnson, in response to the (real) complexity of J2EE (Java 2 Platform, Enterprise Edition) and in particular that of EJB 2 (Enterprise Java Beans). Since then, Spring and Java EE never stopped competing and influencing each other:

  • The arrival of Spring (and Hibernate) has caused a beneficial electroshock in the Java EE community which has given birth to EJB 3 and JPA 1, part of a much more approachable Java EE 5 released in 2006,
  • Spring Batch directly influenced the Batch specification (JSR 352),
  • Spring Dependency Injection inspired CDI (Context and Dependency Injection),
  • Spring has always opportunely used the standards from J2EE and Java EE that were of interest to them such as Servlet, JMS, and JPA,
  • Still today, Spring 5 claims to be compatible with Java EE 8.

Since its creation, Spring has been able to please developers thanks to a pragmatic approach and a very good time-to-market allowing to quickly adopt technological innovations: NoSQL, AMQP, microservices, cloud-native applications…

Since 2006, Java EE has also prioritized simplicity and developer friendliness but with a slower time-to-market due to two main reasons:

  1. The length of time it takes for specifications to be developed within the JCP (Java Community Process): even with a light process, it takes more time to reach an agreement when involving a large number of stakeholders rather than when acting alone,
  2. Implementation and certification time: it often takes several months after a specification release to find supporting and certified Application Servers.

Recently, this gap has widened:

  • Spring Boot has dramatically increased ease-of-use by pushing the convention over configuration principle to the maximum,
  • Spring Cloud has helped address the new challenges related to Cloud-Native developments by leveraging Open Source components from Netflix ensuring service registry/discovery, resiliency, load-balancing, monitoring…
  • Spring 5 has given to reactive programming the status of first-class citizen.

On its side, Java EE has been (much) slower. After a good version 7 released in 2013, a blurry period has set in. In 2016, under the influence of the community, Oracle announced a new Java EE roadmap:

Java EE 8 was released in September 2017, an interesting and highly expected but not revolutionary version. More expectation was put on Java EE 9 in terms of innovation. Except that Java EE 9 will never exist!

In parallel, the Microprofile.io project was launched under the Eclipse Foundation in mid-2016 and gave a new momentum to the Java EE Ecosystem aiming at optimizing Enterprise Java for a microservices architecture. Microprofile 1.0 was based on three specifications representing the least amount of APIs required to build a microservice: JAX-RS 2.0, CDI 1.2 and JSON-P 1.0. MicroProfile 1.2 was released in September 2017 with additional features including Configuration, Fault Tolerance, JWT, Metrics and Health Check. It is expected that version 2.0 will align all APIs to Java EE 8.

Transitioning to EE4J

EE4J aims to offer a more collaborative and responsive way of working. However, the prerequisites for success are not negligible:

  • Transfer of all Java EE 8 assets (for each specification: documentation, Reference Implementation, and Test Compatibility Kit). This is an ongoing work as explained by David Delabassee,
  • Implementation of a new governance model and operating system: both flexible and well-organized. A significant step has recently been achieved with the publication of the EE.next working group charter,
  • Creation and active animation of a community,
  • Product and package renaming: Oracle does not allow EE4J to reuse the “Java EE” trademark and the javax package (for new specifications). Another name must, therefore, be found. The final vote is open with two options: “Jakarta EE” or “Enterprise Profile”, Even if this renaming is not dramatic in itself, it will require an additional evangelization effort among developers and companies.

Once these elements are in place, EE4J will be able to evolve and adapt to the requirements of cloud-native applications and the changes of the Java SE platform, in particular, Java Platform Module System, which will undoubtedly require a lot of substantial work.

An opportunity for reconciliation?

Beyond governance and technical aspects, EE4J will have to find legitimacy because its status as a standard will disappear outside the scope of the JCP. In this context, EE4J cannot afford the luxury of a fratricidal war against Spring. More broadly, I would say that the overall Java ecosystem cannot afford such luxury. Java’s hegemony for server applications is over and competition is fierce with valuable alternatives such as Node.js, Go, and Python. It would be good to join forces to give a new impetus to bring community and industry together.

Why not? If EE4J delivers a set of independent “à la carte” and compatible specifications,
Spring teams would be able to make specific contributions to those that interest them making then Spring framework a major actor for EE4J.

As developers and users of Java, we all have an interest in it. I have a dream … Will it come true?

 


This post was written by a Java EE Guardian, Jean-François James, and first appeared here. James is a Software Architect and a JCP Associate Member with more than 30 years of experience in IT and still passionate about it. He is a DevOps advocate who worked on both sides of the “Wall of Confusion”, Head of Worldline France Expert Network and Atos “Distinguished Expert”.