The Eclipse Foundation recently released versions 1.4 and 2.0 of MicroProfile, featuring updates to the APIs and the addition of comprehensive Test Compatibility Kits (TCKs), Maven coordinates, Javadocs, and Git tags for each API. These versions are fully aligned with Java EE 7 and Java EE 8, respectively.
MicroProfile 1.4
Version 1.4, an upgrade from version 1.3, will be the last in the series of 1.x releases that include security and other enhancements to the following APIs:
- Open Tracing (add component tag to server).
- Rest Client (add asynchronous methods and better integration with other MicroProfile APIs).
- Fault Tolerance (updates to its SPI and interaction with the Metrics API).
- JWT Propagation (add support for configuring the public key).
- Config (improvements to implicit converters and security updates).
MicroProfile 1.4 is fully aligned with Java EE 7 and code examples can found on GitHub.
MicroProfile 2.0
Two years after its inception, MicroProfile 2.0, an upgrade from version 1.4, is the latest release that includes updates to the CDI, JSON-P, and JAX-RS APIs. Also, a new API, JSON-B, has been added for version 2.0.
MicroProfile 2.0 is fully aligned with Java EE 8. New features include:
- New capabilities from Java EE 8 APIs
- Improved ease of use
- CDI-based and programmatic easy-to-use interfaces
- More integration points among the APIs
MicroProfile 2.0 will serve as the base for future upgrades. As stated in the release:
Eclipse MicroProfile continues to deliver additional value with each release and to successfully evolve with the dynamic help of all its community members. Future releases will update existing APIs and add new ones. As an example, the community has already started discussing the following topics:
- Long Running Actions
- Reactive Streams
- Reactive Events
- Data Access
- Event Data
MicroProfile and Jakarta EE
The synergies between MicroProfile and Jakarta EE have sparked some speculation that the two platforms could merge.
Kevin Sutter, MicroProfile architect at IBM, stated in a recent blog post:
This is one of the most common questions I get on forums, conferences---even internally at IBM. Eclipse MicroProfile is fairly well-established with several key features and releases under its belt and the future of Java EE is now being established with Eclipse Jakarta EE. When will these two forces combine? This is a difficult question.
Both of these Eclipse projects have merit and are making progress in their respective domains, with MicroProfile technologies building upon those being contributed to Jakarta EE. But are the projects themselves ready to be merged? IMHO, no. MicroProfile has grown tremendously from its humble beginnings. We have several new component features and versions that extend the Enterprise Java programming model for microservices development. And we have done this in a relatively short amount of time: Six major MicroProfile releases with sixteen component releases in less than two years.
Due to the enormity and complexities of this move, Jakarta EE is not yet ready to match this rate of progress. And, as Jakarta EE has not yet completed the definition of its specification process, it is not yet ready to accept the fast-paced release cycle required by MicroProfile. The big difference here is that MicroProfile has never tried to be a standards body. MicroProfile produces industry-accepted specifications, not standards. Jakarta EE is trying to replace the JCP Standards body with a more modern, open, and lightweight implementation-first process.
The reactive programming model effort will eventually target Jakarta EE. The team from Lightbend was looking for the best way to incorporate some of their reactive programming ideas into the Enterprise Java space. They determined that the quickest way to make some immediate progress was to develop a MicroProfile component.
Lightbend, a relatively new participating member of Jakarta EE, recently named James Roper, senior developer and co-creator of the Lagom microservices framework at Lightbend, as the first contributor to represent Lightbend on the MicroProfile team. When asked in a recent InfoQ interview on how he plans to contribute to MicroProfile, Roper stated:
My contribution (and the broader contributions of Lightbend) will primarily be around new Reactive specifications. The first thing we've done is help outline an approach for writing Reactive APIs and adopting Reactive features in MicroProfile. As a product of penning this approach, we identified that MicroProfile needs a Reactive Streams manipulation API, to allow MicroProfile developers to interact with Reactive Streams.
A specification for this API is well on its way to being finished. This leads into the next specification, called MicroProfile Reactive Messaging, which allows Reactive Streams based consuming, publishing and processing of messaging streams between services. This is where most of our focus is on at the moment.
Going forward, once these specs are complete, we will continue to look for ways that MicroProfile can benefit from Reactive approaches, and look to contribute in those areas. Just today the topic of MicroProfile persistence has come up, and at Lightbend we have a lot of experience solving the difficulties in persistence that don't occur in monoliths due to using a single database with ACID transactions, so I've joined those discussions and will seek to bring our experience to that.
Sebastian Daschner, IT consultant, software developer and architect, stated in a recent blog post:
Since its creation, MicroProfile has gained a lot of traction and produced a variety of specifications. Originally, it was created to advance enterprise Java for a microservice world, with faster progress, driven by multiple vendors. Now, with Java EE being transformed to Jakarta EE under the Eclipse Foundation, how does MicroProfile reasonably fit into the picture within the Enterprise Java universe?
In general, it's crucial that the Java Enterprise community shares a common, clear image what MicroProfile's place will be in the future. Next steps in pursuing the idea of MicroProfile serving as an incubator for Jakarta EE would be to define and agree on:
- Shared technical design principles for both Jakarta EE and MicroProfile.
- Naming, branding, and namespaces for incubating MicroProfile.
- A common process for future MicroProfile projects and incubation into Jakarta EE.
Resources
- MicroProfile - Collaborating to Bring Microservices to Enterprise Java by Rich Sharples (June 27, 2016)
- Dynamically Update Your Microservice Configuration in Liberty August beta by Laura Cowen (August 3, 2018)
- MicroProfile's Role in the Age of Jakarta EE by Sebastian Daschner (August 3, 2018)
- MicroProfile REST API with MongoDB, Hibernate OGM and Thorntail by Hayri Cicek (August 7, 2018)
- Your Own MicroProfile Config Source by Philip Krüger (August 10, 2018)
- What's Next for MicroProfile and Jakarta EE? by Kevin Sutter (August 16, 2018)
- Reusable MicroProfile Health Probes by Philip Krüger (August 20, 2018)