Java EE – MicroProfile.io – Jakarta EE

The Java EE platform is one of the main tools for creating enterprise applications, thanks to a series of standards and specifications whose implementations have allowed us to manage crucial aspects such as transactions, security, scalability, concurrency, and management of the components it is deploying.

Together with Spring and Pivotal technology, Java EE represents the implementation model for modern Java-based enterprise applications on any kind of deployment platform.

As previously stated, the delay in the evolution of the platform and, consequently, in the release of new versions able to meet the new requirements related to the implementation of microservices in cloud environments have generated in the community a sense of distrust in its use.

I don't want to start some sort of religion war on which technology among Java EE, Spring, or others is regarded as the best to implement modern applications. Java EE 7, the latest stable and supported version, was released in 2013, and it received very positive feedback from the community.

Spring's influence on Java EE was clear and helped to improve the platform by making it significantly less complex for example, through the following:

• The arrival of Spring and Hibernate has provided new ideas and approaches to development, which has given birth to EJB 3 and JPA 1, which represent the two major innovations introduced in Java EE 5.
• Spring Dependency Injection was the base on which Context and Dependency Injection (CDI) was built.
• Spring Batch has merged into JBatch specification (JSR 352 https://www.jcp.org/en/jsr/detail?id=352).

Since its creation, Spring has become popular among developers, thanks to the ease-of-use approach and a speedy time to market that allow us to quickly adopt technological innovations, such as microservices and cloud native applications.

Java EE, instead, and in particular after version 5, has a slower time to market; the reasons are related to the length of time needed to write specifications, and the implementation and certification time. Usually, several months are needed for a specification release to be supported and certified by the application servers.

Recently, this gap has widened:

• Spring Boot has increased its ease of use through the convention-over-configuration principle.
• Spring Cloud is becoming the major platform used in cloud-native developments by leveraging open source components from Netflix, which creates modules that implement important cloud concepts such as service registry, service discovery, load balancing, monitoring, and so on.

Now the question could be—is Java EE still a good choice to make microservices and cloud-native applications?

In my opinion, the answer is yes.

First of all, Java EE, in particular version 8, introduced or has consolidated a great number of specifications that are extremely useful for microservices implementation, such as the following:

• CDI 2.0 
• Java API for JSON Processing (JSONP) 1.1 
• Java API for JSON Binding (JSON-B) 1.0 
• Java API for RESTful Web Services (JAX-­RS) 2.1 
• Java Servlet 4.0

CDI 2.0 defines the behavior of CDI outside of a Java EE container, allowing the use of patterns such as inversion of control even in contexts such as third-party utility libraries.

The specification is split in three parts—core CDI, CDI for Java SE, and CDI for Java EE. This split makes CDI more modular in order to help other Java EE specifications better integrate with it.

The de facto standard for API communications in microservices environments is the JSON format. Java EE has two great specifications, JSON-B and JSONP that can help developers to easily produce and process a JSON payload.

JSONP has great support, with utilities such as JSON Pointer, JSON Patch, JSON Merge Patch, and so on, for meeting the Internet Engineering Task Force (IETF) standards (https://www.ietf.org/standards/). It has also added editing operations to JSONObject and JSONArray, and introduced helper classes and methods to better utilize Java SE 8 Stream operations.

JSON-B set a JAXB-­like API to easily marshal or unmarshal Java objects to/from JSON. It created a default mapping between classes and JSON, and a standard support to handle the application/JSON media type for JAX-­RS. It's a natural follow-on to JSON­P specifications, and closes the JSON support gap.

JAX-RS 2.1 standardized some features most used in microservices development, as follows:

• Server-­sent events
• Non-­blocking I/O in providers (filters, interceptors, and so on)
• Reactive programming paradigms to improve JAX-­RS asynchronous clients
• Hypermedia API enhancements

In this way, it has facilitated integration with other JSRs and frameworks.

Servlet 4.0 introduced support for HTTP/2 protocol and the use of request/response multiplexing, server push notifications, and so on. It's also aligned with the latest HTTP 1.1 RFCs.

All the specifications and features described previously are certainly useful, but not sufficient to make Java EE suitable to meet the needs of cloud-native applications and microservices.

Now, the main targets are as follows:

• Deploy the applications onto the cloud
• Build microservices in an easy manner
• Enable more rapid evolution of applications

The community, through the Java EE guardians (https://javaee-guardians.io/) and the Java User Groups (JUG), pushed for modernizing Java EE for cloud and microservices environments. The target is to extend the Java EE platform in order to make it able to build microservice architecture, while still maintaining backwards compatibility with previous Java EE versions. Furthermore, the community wanted a migration path to evolve the consolidated applications into cloud-ready applications that could take advantage of new cloud development and deployment models.

In detail, the request was to obtain functionalities as follows:

• Client-side circuit breakers in order to make remote REST invocations fault-tolerant
• A standard way of health checking Java apps
• A secret vault to shadow sensitive data
• Multitenancy support to accommodate the needs of complex applications
• OAuth and OpenID support technologies have rapidly emerged as a de facto standard in security context implementation
• An externalized configuration store to make it an easy process to promote applications across environments

The answers to these requests were essentially two, as follows:

• The creation of the MicroProfile.io project, in the middle of 2016
• The new life on Java EE with the Jakarta EE community project at the end of April 2018