Jakarta EE/MicroProfile Prospects for 2021
The year in enterprise Java!
Join the DZone community and get the full member experience.Join For Free
Certainly, 2020 will be a milestone in history for several reasons. Within the Java community — in addition to the popularization of Quarkus — there was a lot of work and effort within the Eclipse Foundation with Jakarta EE and MicroProfile. Let's go over a little about this news and the great achievements made last year, in addition to the projections and expectations for the coming year.
It is always good to speak of the great importance of the Eclipse Foundation. In addition to the IDE, which is one of the most used tools in the Java world, the Eclipse Foundation is a space for collaborative innovation and a process that ensures that all this intellectual property will be linked to open source.
Jakarta EE/MicroProfile Retrospective
Looking back at this year for both platforms, we can start with online events related to Jakarta; Jakarta One has had five editions in several languages such as Portuguese, English, Japanese, and Spanish.
When we talk about launches, within the Jakarta EE world, we have its ninth version and with its biggest impact since all packages that were once “javax” become “jakarta”. In the MicroProfile world, version 4.0 was launched by creating a working group and a specification process. This launch of MicroProfile allows mutual assistance between the two projects. Before version 4.0 of MicroProfile, only MicroProfile could use the Jakarta EE APIs, as is already the case, for example, with CDI, JAX-RS, etc. However, it will now be possible for a mutual contribution of which the Jakarta APIs will also use the MicroProfile.
The Next Steps
To avoid major impacts in a single version, Jakarta EE 9 was still released compatible with Java 8. With this release made, the next step is to launch a new version compatible with Java 11.
On the MicroProfile side, there is already a discussion about having a version compatible with Jakarta EE 9, as well as how this integration would work.
The other point is the launch of Cloud Native for the Java (CN4J) Alliance, on which integration of the two platforms is based. Despite not getting a written definition of the term “cloud-native”, we know that the future of development and architecture will be linked to the cloud's computational model.
As Confucius would say: "If you want to predict the future, study the past", so it is important to show a little of the history and events of Jakarta EE in recent years.
In 2016, Java EE received several complaints from the community due to the slow pace of deliveries and participation in the platform, mainly related to the specifications for which Oracle was responsible. It was at this time that Reza Rahman led the creation of an interest group in this technology, at the time, formed as Java EE guardians. Today this group is called jakartaee-ambassadors.
That same year, the Devoxx UK and DevNation conferences started discussing a new project, whose focus would be to help Java EE until then. And in 2016, Java officially announced the Eclipse Microprofile. The initial members were the same as those of the JCP executive committee group: IBM, Red Hat, Payara, Tomitribe, LJC, Payara, and SouJava.
One of the premises of the platform was to help the innovation process that was so lacking within Java EE. Thus, its initial motto was:
A fast and innovative interaction;
Through JSR returning to Java EE, the pattern was tried with the configuration API in JSR 382.
However, this story becomes more interesting when in 2017 Oracle decided to donate the code and all intellectual property to the Eclipse Foundation a few months after donating the NetBeans codebase to the Apache Foundation.
Prospects for the Future
Once given the historical context, the first point that we need to discuss would be the organization. In the past, Java EE and MicroProfile had a sense of separation. However, currently, the two projects are part of the same organization, the Eclipse Foundation. The Cloud Native for Java (CN4J) Alliance intends to unite them in some way.
Another important point is the new specifications that tend to enter the Jakarta EE family this year. They will be:
Jakarta NoSQL: The first specification that was born within Jakarta EE. It aims to facilitate the integration between the Java world and NoSQL.
Framework Flavors From Reading Metadata
One of the topics that are certainly generating a great discussion in the world of frameworks is about the metadata readings within a Java class, be it the options or the impact of each one. But what does that mean? The final developer tends not to have much change concerning the API or annotations that it has been using. However, for the architecture of the frameworks, this tends to require many changes. In general, the frameworks work with the use of reflection in the Java world. This has a big problem since the reading of the class metadata happens at runtime, not in ReflectionData. The use of Reflection tends to degrade both start-up and increase memory consumption.
Another option would be to bring this entire process of generating metadata at compile-time; that is, when executing the information, the metadata would already be processed and do not need to use reflection resources, thanks to some components such as the Java Annotation Processor, for example, in cases that need a good start-up like serverless. Another benefit is the possibility of using the code in native mode.
Based on several success stories from various frameworks, Java supports native code with GraalVM, such as Quarkus, Helidon, Micronaut, and Spring. There are also several initiatives for specs to also explore this type of resource such as CDI Lite.
Modularization vs. Profiles
In version 6 of Java EE the first profile was launched: WebProfile. As the name says, it is a profile focusing on reducing disk consumption. WebProfile would have eight specifications about the complete Java EE, which held all the specifications, having a total of twenty-four.
There is a proposal to create another profile, LiteProfile, which would be lighter than the WebProfile.
On the other hand, there is another option: modularization. The great advantage of this approach is the possible precise choice of dependencies for that particular application. This model with modules is a solution that has been used successfully in some Java frameworks such as Quarks, Spring, Helidon, among other platforms within the Java world. Another advantage is that as the number of combinations between specs is large, it is necessary to have many profiles to retain all combinations. With the modules, this would happen quite naturally.
The Year of Services
The use and adoption of the cloud are imminent and inevitable. However, to speed up this process, there is a type of service that aims to decrease complexity and increase abstraction, reducing the risk of using the cloud computing model. Within the book 97 Things Every Cloud Engineer Should Know, Dan Moore explains the importance and ease of using managed services since, besides the infrastructure, this type of service grants the know-how to manage and maintain software. With this, important activities such as updating the database, Java version, performing a backup, managing application and database access for security, etc., will be transferred to this type of service, making the team of developers focus on delivering the business.
Developing close to MicroProfile and Jakarta EE, there are cloud management services that support both platforms; those are some samples:
Payara Cloud: is an easy way to manage the application server in the cloud.
Platform.sh: A PaaS that aims to manage the application and the services that the application needs, such as a database. The PaaS approach focuses on infrastructure as code where the team puts all dependencies into configuration files. The entire configuration will be in charge of PaaS using the GitOps concept strongly.
These are some of the examples that work with MicroProfile and Jakarta EE and are also managed services in the cloud; even though this cloud facility is not directly linked to the process, it certainly helps in the Java's popularity environment in the cloud. It is believed that this year, this popularity tends to grow much more.
Looking at the past and the present, both from MicroProfile and Jakarta EE, it is possible to perceive a substantial future perspective. Transparency and collaboration are some of the great foundations within the Eclipse Foundation. From the points under discussion for this year, the highlights, certainly, will be the migration to Java 11, the union and tuning of the two projects, the definition of whether the projects will have more modules or if they will be more focused, in addition to many other things! The best part is that everyone in the Java community can participate and make the future instead of just watching it.
Opinions expressed by DZone contributors are their own.