Proposal to define relationship between Jakarta EE and Eclipse MicroProfile
What’s new for Jakarta EE and Eclipse MicroProfile? Discussion and proposals help to move us forward day by day. Sebastian Daschner proposes formalizing Jakarta EE’s relationship with Eclipse MicroProfile and incubators, as well as some new standards and updates to old ones. Let’s take a closer look.
Java Champion Sebastian Daschner has published a blog post proposing to clarify exactly what the relationship will be in the future between Jakarta EE and Eclipse MicroProfile. Previously he had suggested that Eclipse MicroProfile become an incubator for Jakarta EE, but in this new proposal he accepts that Eclipse MicroProfile is more established now than it was and is known for being more than an incubator technology. The proposal places strong emphasis on the need for Jakarta EE to innovate and progress, something that Eclipse MicroProfile has proven to be very successful at. With that in mind, let’s take a look at the details.
New standards and processes to move faster
Daschner proposes the need for some new standards and wants to open up the discussion about the future of Jakarta EE. In particular, he emphasizes the need to innovate and advance without getting weighed down by standards. As such, he proposes an umbrella setup that will make sure the different technologies still work well with one-another, as well as agreeing on standards that will make it as easy as possible to use Jakarta EE and its incubators and to update once newer versions are incorporated into the baseline.
Eclipse MicroProfile’s establishment of itself as an innovator in production-ready tools is something he considers to be more than just an incubator for Jakarta EE now. His proposal and subsequent comments in the Eclipse mailing list stress that he wants to keep Eclipse MicroProfile working the way it is now, but wants to formalize the cooperation with Jakarta EE so that everyone is on the same page.
Daschner talks a lot about incubators in his proposal because he sees them as the drivers of innovation. He suggests taking long-running Jakarta incubators and rebasing them on a more recent version so they will be more accessible for users.
He also places value on the reuse of technology in the baseline. All this to make it easier for incubators to become included in the baseline, for which he proposes a simplified process that includes documentation and code examples. Ideally, the documentation will also explain the motivation and thinking behind the technology so users can get to grips with it faster.
The same will apply to specifications, with documentation that is aimed at users and also contains commonly used code examples.
Included in the proposal is more detailed information about exactly what new standards Daschner proposes, as well as what updates and what new incubators.
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 Eclipse 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
SEE ALSO: Jakarta EE 8 gets a release date
As for Eclipse MicroProfile, clearly they have been thinking about their future relationship with Jakarta EE and posted a blog yesterday where they address the question of whether Eclipse MicroProfile and Jakarta EE will be merged. The answer? “They don’t target the same goals and they don’t have the same lifecycle. They are no plans or willingness to merge them at the moment.”
As for Daschner, he wrote:
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.
One thing is abundantly clear right now: it’s all hands on deck getting Jakarta EE 8 ready to go. It seems quite likely this topic will be parked for a little while