Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Road to MicroProfile 4.0

The Road to MicroProfile 4.0

This item in japanese

Lire ce contenu en français

Originally scheduled for a June 2020 release, MicroProfile 4.0 was delayed until an Eclipse Working Group was established as mandated by the Eclipse Foundation. Operating independently since its inception in 2016, there were a total of 12 MicroProfile releases by a dedicated group of contributors from within the Java community. MicroProfile 3.3, released in February 2020, is the latest version of MicroProfile.

Roberto Cortez, SmallRye project lead at Red Hat, provided a retrospective on the previous work by the MicroProfile community, writing;

In these last 4+ years, the MicroProfile community has grown beyond the most optimistic expectations. We believe that the core values that have been part of MicroProfile since its very beginning, like a lightweight process, vendor-neutrality, transparency, accountability, innovation, and implementation first, are the keys to the project's success.

Introduced at Red Hat's DevNation conference on June 27, 2016, the MicroProfile initiative was created as a collaboration of vendors to deliver microservices for enterprise Java. The release of MicroProfile 1.0, announced at JavaOne 2016, consisted of three JSR-based APIs considered minimal for creating microservices: JSR-365 - Contexts and Dependency Injection (CDI); JSR-374 - Java API for JSON Processing (JSON-P); and JSR-370 - Java API for RESTful Web Services (JAX-RS).

Shortly after the release of version 1.0, MicroProfile joined the Eclipse Foundation to ensure that this initiative would remain vendor neutral and leverage some resources. However, the transition wasn't easy. As InfoQ reported:

The required paperwork has been rather onerous, and arguments have been raised regarding the package naming convention MicroProfile should follow, and regarding the license under which the project should be published.

In the end, contributors finally accepted to follow Eclipse Foundation's naming standards, while the foundation accepted to have the project published under ALv2, as opposed to EPL, the standard for Eclipse projects.

By the time MicroProfile 1.3 was released, eight community-based APIs complementing the original three JSR-based APIs, were created for building more robust microservices-based applications. A fourth JSR-based API, JSR-367 - Java API for JSON Binding (JSON-B), was added with the release of MicroProfile 2.0.

After months of weekly meetings that were open to the MicroProfile community, the MicroProfile Working Group (MPWG) Charter, consisting of a Steering Committee and various levels of membership, had passed the review process in September and was ultimately approved at the very first MicroProfile Steering Committee meeting on October 20, 2020. The MicroProfile Steering Committee includes the following organizations and Java User Groups (JUGs): Atlanta JUG, IBM, Jelastic, Red Hat and Tomitribe.

According to the release plan, MicroProfile 4.0 has been scheduled to be released on November 10, 2020, just ten days before the formal release of Jakarta EE 9. Milestone and release candidates were allowed to be released while the MPWG Charter was being drafted. MicroProfile 4.0 RC1, just released on October 23, 2020, contains updates the eight community-developed APIs:

The four MicroProfile JSR-based APIs: CDI, JSON-P, JAX-RS and JSON-B, are now based on their equivalent Jakarta EE specifications for MicroProfile 4.0.

John Clingan, senior principal product manager at Red Hat, spoke to InfoQ about the upcoming release of MicroProfile 4.0.

InfoQ: After four years of solely operating as a community-based process, how will the creation of the MicroProfile Working Group benefit MicroProfile moving forward?

John Clingan: The primary driver behind creating the MicroProfile Working Group is to close intellectual property gaps identified by the Eclipse Foundation for specification projects. So, there are more legal protections in place now that MicroProfile is a Working Group.

A Working Group also places more processes on MicroProfile. Historically, MicroProfile moved quickly with minimal process and late-binding decisions. It was quite an agile project that delivered specifications at quite a quick pace. However, I personally feel like we were reaching a point where adding *some* process can benefit the project. For instance, we now have to put more thought and formality up-front into planning a specification, which requires a Steering Committee vote. Better planning gives implementors, tool vendors, and the community more up-front visibility into what is coming and prepare. However, we codified "limited processes" in the MicroProfile Charter to keep processes to a minimum.

InfoQ: There were three to four new releases in 2018 and in 2019. Will the MicroProfile release schedule change as a result of the new Working Group?

Clingan: We formally planned and delivered three releases per year - February, June, and October. Typically June is reserved for major and potentially backward-incompatible releases. Forming a Working Group definitely impacted the schedule. We hope to deliver two releases this year, with MicroProfile 3.3 having been delivered in February and MicroProfile 4.0 targeting November or December. I suspect next year we'll have two releases since the time between MicroProfile 4.0 and February 2021 is too short. However, we haven't nailed that down yet. We're pretty focused on delivering MicroProfile 4.0 right now.

InfoQ: What were the most significant challenges in creating the MicroProfile Working Group Charter?

Clingan: A big challenge was switching from being a fast-moving agile project to fitting into the process structure required by a Working Group. We wanted to maintain as much of our existing culture as possible because the community was consistently delivering three annual releases. It was figuring out where we wanted to minimize formality and processes because they added minimal value to how we were already operating. It was also embracing other processes because they did add value.

Also, there was a lot of discussion on whether or not MicroProfile and Jakarta EE should exist within the same Working Group or as two separate Working Groups. The result is two separate Working Groups, but we continue to discuss the alignment between the two Working Groups.

InfoQ: Please explain to our readers the differences between Steering Committee members, Committers and Contributors in the MicroProfile Working Group Charter?

Clingan: In MicroProfile, the Steering Committee includes Corporate, Committer, and Guest Members.

  • Corporate members are organizations that want to be directly involved in moving MicroProfile forward, and they also fund the Working Group through annual fees.
  • There is also one committer member who is a MicroProfile committer that is not employed by a corporate member. That number may grow in the future.
  • Guest members want to show support for MicroProfile and are typically involved in some way. For example, they may want to show their organization's logo on the web site.

Collectively, Corporate and Committer Members have binding votes to create/approve specification releases and amend the charter. Everything else happens in the community. More complete descriptions are in the charter.

MicroProfile committers are those who have commit rights to code repositories. Like every Eclipse Foundation project, it is a meritocracy.

The charter does not explicitly formalize "Contributors." As a Working Group, we see contributors as those who contribute to MicroProfile in ways that are not always code, like writing white papers or marketing. MicroProfile puts a heavy emphasis on non-coding contributor involvement because it is critical to the success of MicroProfile.

InfoQ: How can organizations and JUGs sponsor or contribute to MicroProfile?

Clingan: The best way is to join the Google Group and start participating in conversations. Introduce yourself (or your organization) and area of interest. Everything else, contributions and sponsorships, flows from there. Feel free to join individual specification meetings or the live hangouts scheduled on the MicroProfile Calendar.

More recently, the Eclipse Management Organisation (EMO), a United States incorporated non-profit company composed of Eclipse Foundation employees, has accepted the MPWG Charter and has added it to the collection of Eclipse Working Groups.


Rate this Article