The Jakarta EE Ambassadors are encouraged by the continued progress and relevance of both Jakarta EE and MicroProfile. We believe a clear, collaborative, and complementary relationship between Jakarta EE and MicroProfile is very important for the Java ecosystem.
Unfortunately the relationship has been unclear to many in the Java community, sometimes appearing to be disconnected, overlapping and competitive. MicroProfile builds on top of some Jakarta EE specifications and many Jakarta EE applications now use MicroProfile APIs. For the success of both, it is imperative that the technology sets clarify alignment to ensure continuity and predictability.
The Cloud Native for Java (CN4J) Alliance was recently formed to address these concerns. The alliance is composed of members from both the Jakarta EE and MicroProfile working groups. The Jakarta EE Ambassadors view this as a positive step. This joint position statement and the additional slide deck linked below summarize what the Jakarta EE Ambassadors would like to see from CN4J as well as the alignment between Jakarta EE and MicroProfile.
We see Jakarta EE and MicroProfile fulfilling distinctly important roles. Jakarta EE will continue to be the stable core for a very broad ecosystem. MicroProfile will continue to strongly focus on microservices, velocity, and innovation. Our perspective on each is as follows:
Jakarta EE
- One major release per year
- Targets monolithic applications, microservices and standalone (Java SE/command line) applications – both on premises and on the cloud
- Maintains a stronger commitment to backwards compatibility
- Enables specifications to be used independently
- Enables the ecosystem to build on Jakarta EE technologies, including MicroProfile and Spring
MicroProfile
- Multiple releases per year
- Targets microservices and cloud native applications
- Strongly focuses on innovation and velocity including domains such as OpenTelemetry, gRPC, and GraphQL
- Depends on core technologies from Jakarta EE
- Less stringent requirements on backwards compatibility
It does appear the majority of our community would like to see eventual convergence between the technology sets. It is nonetheless understood this may not be practical in the short term or without its drawbacks. It is also clear that some very mature MicroProfile specifications like Configuration need to be used by Jakarta EE. We believe the best way to meet this need is to move these specifications from MicroProfile to Jakarta EE. The specifications being moved should adopt the jakarta.* namespace. The transition should be a collaborative effort. This is in accordance with what we believe developers have said they want, including through multiple surveys over time.
Jakarta EE also needs to make some significant changes to better serve the needs of MicroProfile and the Java ecosystem. One key aspect of this is enabling specifications to be used independently, including standalone TCKs. Another key aspect is focusing on Jakarta EE Profiles that make the most sense today:
Core Profile
- Core Jakarta EE specifications needed by MicroProfile
- Some specifications moved from MicroProfile such as Configuration
- CDI Lite
Full Profile
- All Jakarta EE specifications
- Deprecate/make optional older technologies
Jakarta EE and MicroProfile are both critical to the continued success of Java. We are committed to working with all key stakeholders towards a strong alignment between these technology sets. We invite all developers to join us in ensuring a bright future for both Jakarta EE and MicroProfile.
Additional Material