I have to say this is just awesome. Thanks for doing this. Do you mind if I propose that the Java EE Guardians republish this content and amplify it?
While the current heads down focus is Jakarta EE 8, I fully agree with you there is no real way of deferring this discussion in the broader community. Everybody wants to know what happens the day after Jakarta EE 8. Might as well start somewhere and this looks like a pretty good starting point to me in terms of getting people thinking.
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Hi there,
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.
I've created a blog post [1] on this topic which I wanted to cross-post here on this list. Feel free to forward or redirect me to a different mailing list that potentially fits better.
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 [2], 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
As always, anything is up for discussion. WDYT?
Sebastian
[2]
https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee