Proposal on Jakarta EE’s innovation & relationship with MicroProfile

#microprofile #jakarta tuesday, july 23, 2019

At the JCrete unconference, a few of us were brainstorming about the vision of Jakarta EE and especially the relationship with MicroProfile. I wanted to start that discussion in order to get everybody on the same page especially how the relationship between Jakarta EE and MicroProfile, and Jakarta’s innovation should look like. I believe that a lot of us agree on things already, however, I believe it would accelerates the process if we start that discussion.

The following is a proposal on the bigger picture of the Jakarta standardization process, the relationship with MicroProfile, and the fact that there is a need for an incubation process. Please note that everything is up for discussion. My original view was to use MicroProfile as an incubator for Jakarta, however, some folks within the community have expressed their concerns with that idea since the MicroProfile brand gets more and more established and is seen as more than just an incubator technology.

Motivations & reasoning

There is a huge need to advance and innovate on Enterprise Java. Also, we need the possibility to innovate and discard some of the innovation without being carved in stone in standards, already.
We need a process to rebase the incubators on the baseline, in order to use updated APIs from other specifications.
We need an umbrella that ensures that multiple technologies work well together. The incubator projects need to work well with the baseline specifications as well.
We need to make it as easy as possible for end users to use Jakarta EE and its incubators and to update to newer versions once things get incorporated into the baseline.
We need to agree on the details of incubators and standards, regarding format and contents of technical documentation, examples, and Java packages.
MicroProfile is establishing its brand and ecosystem which is seen as production-ready technology (more than just an incubator) and which is something we might want to keep.
We might want to start these considerations now, in order to align stakeholders and to decide what the picture looks like, even things only get realized weeks and months from now.

Proposed process

The Jakarta umbrella contains specifications that are part of the baseline (which corresponds to the Java EE umbrella).
Jakarta incubators are the typical way to innovate and advance Jakarta in newer technologies. Published versions of incubators can be used in combination with the Jakarta baseline, and offer a quicker way to implement and discard things.
Jakarta incubators are based on a specific version in the baseline branch and can and should re-use the technology contained in the baseline. Incubators use the same design principles and the jakarta Java package in order to make it easy for early adopters to switch from incubator dependencies to specifications.
Longer-running Jakarta incubators can and should be rebased to a recent Jakarta version in order to use the latest technology and to facilitate usage for implementers and users.
Jakarta incubators that have proven themselves can get included into the baseline branch as proper Jakarta standards. In order to make that transition easier, incubators use the jakarta Java package and follow a certain (simplified) process on documentation, specification, and code examples. However, everything inside an incubator may change before transformed into a Jakarta specification.
All Jakarta incubators and specifications need to provide a specification, targeted to implementers and users, as well as documentation and getting-started code examples on commonly-used patterns, targeted to users. The documentation must include a short motivation why and in which cases the technology is required, and enable users without prior knowledge to get started quickly.
The MicroProfile brand and ecosystem stays as is and can continue to evolve as is with all its current projects. Jakarta incorporates the efforts and innovation that already happened within MicroProfile, with adaptions where required. Once Jakarta includes new specifications, for example Config, it might make sense to rebase MicroProfile to then include these new standards instead of its current projects.

Diagram

I propose to advance the future of Jakarta EE with the following technology:

New standards in Jakarta EE

Configuration (Jakarta-Config) will be a new specification project in the Jakarta baseline. It originates from the efforts behind the withdrawn Config JSR, and MicroProfile Config.
Model View Controller (from JSR 371)
JCache (from JSR 107)
Deployment specifications: standardizing the way how to deploy and modern apps, how to provide libraries, what the runtime directory layout looks like, thin deploy artifacts, etc.

Updates on EE standards

Concurrency: incorporating approaches from mp-context-propagation and bulkheads from mp-fault-tolerance
Security: incorporating approaches from mp-jwt-auth
JAX-RS: incorporating approaches from mp-rest-client where reasonable

New incubators in Jakarta EE

Fault-tolerance: circuit breakers, timeouts, retries, fallbacks, features taken from mp-fault-tolerance
Observability: features from mp-metrics, mp-open-tracing, mp-health
Testing: incorporating ideas and approaches from Arquillian, Spring Test, Testcontainers, and maybe more
Reactive-streams / messaging: features taken from mp-reactive-streams and mp-reactive-messaging
LRA (or different name): approaches taken from mp-lra
Open API: features from mp-open-api

Further readings

This has been posted to the Jakarta EE WG mailing list as well. Please consider to chime in there with your feedback and comments.

Found the post useful? Subscribe to my newsletter for more free content, tips and tricks on IT & Java: