To fork, or not to fork

There is a very interesting discussion ongoing on the Jakarta EE Community mailing list about forking Eclipse MicroProfile as Jakarta Configuration. While the discussion on the mailing list initially is about the MicroProfile Config specification specifically, it also raises the question of how the strategy of Jakarta EE should be for technical alignment with Eclipse MicroProfile.


A couple of weeks ago, there was a vote in the Eclipse MicroProfile community about how the technical alignment with downstream consumers. Two approaches, the Pull Model and the Push Model were voted on. The Pull Model got the most votes, and thus was selected as the strategy for technical alignment.

In parallel, the discussions regarding the creation of a MicroProfile working group have been going on since October last year. Several suggestions have been explored, including separate working groups, a combined working group with Jakarta EE, or a combination of the two with two working groups linked together with an umbrella working group.

The latest development in this working group discussion is that the Eclipse Foundation has asked the MicroProfile Community to define a charter for a MicroProfile working group independent from Jakarta EE.

Why Fork?

Whether there is a single working group, a group of working groups under an umbrella working group, or just independent working groups is actually not relevant to this discussion. The technical alignment will still be the same. The MicroProfile community has chosen the Pull Model, and this is something Jakarta EE needs to figure out how to relate to.

In my mind, it is pretty simple. Jakarta EE should create a fork of the specifications that makes sense to make a part of the Jakarta EE Platform. There are several reasons for this. I have touched upon a couple of them here.

1. Stability

MicroProfile wants to move fast and break things, while Jakarta EE wants to maintain a certain level of backward compatibility. By creating a fork, Jakarta EE won’t have to address this concern since it will then control the life cycle of its specifications.

2. Cohesion

Java EE, and by succession Jakarta EE, has always been a very cohesive platform. A central piece like configuration will be used throughout the entire platform and it only makes sense that it is in the same namespace as the rest of the platform.

3. Flexibility

By maintaining a fork of the specification, Jakarta EE is free to make modifications that are relevant for Jakarta EE, but maybe wouldn’t be relevant for MicroProfile.

Some Thoughts

As I pointed out in Hashtag Jakarta EE #11, the headache of diverging tines of the fork lands on the vendors that support both Jakarta EE and MicroProfile in the same product. Therefore, it is kind of interesting to see that the vendors that were most in favor of the Pull approach that are all shipping products that are both Jakarta EE and MicroProfile compliant. So, clearly, they must have thought about this and have a solution in place.

Some other reads on the same topic

MicroProfile and Jakarta EE Technical Alignment – Steve Millidge
Proposal on Jakarta EE’s innovation & relationship with MicroProfile – Sebastian Daschner

Election Time

The election for positions at the various committees in the Jakarta EE working group has started. There are seats up for election in the Steering Committee, the Specification Committee, and the Marketing and Brand Committee.

This election consists of one seat for Participant Members and one seat for Committer Members in each of the committees, which means that there are six positions open.

In the following Studio Jakarta EE, I have recorded a little information regarding the election.

To sum up, the nomination period is open until April 10, 2020. So don’t hesitate with nominating yourself!

Hashtag Jakarta EE #13

Welcome to the thirteenth issue of Hashtag Jakarta EE!

EclipseCon 2020 is added to the long list of events that transforms into a virtual event this year. For those with an eye for detail will notice that the conference has changed the name from EclipseCon Europe to simply EclipseCon.

The name change has nothing to do with the decision to go virtual this year. EclipseCon is a global event and has been so for years, so removing the Europe part of the name just makes sense.

The seemingly never-ending story of creating a working group for Eclipse MicroProfile took an interesting turn at the end of this week. In an email to the Microprofile mailing list, Mike Milinkovich tasked the MicroProfile community to come up with a proposal for a MicroProfile Working Group Charter. This means that the efforts of creating a common working group or an Umbrella working group structure in relation to Jakarta EE have been put on hold.

I think it is a good thing that the discussions now can be around how to get the MicroProfile Working Group up and running so we can all focus our energy on technical challenges rather than governance.


A new Studio Jakarta EE recording is available!

In this snippet, I go through the new navigation elements added to the specifications part of the Jakarta EE website. Specifically, links to the Eclipse Project pages and an external webpage if that exists.

A trivia at the end. Which year did we get the shirt I am wearing in the video at JavaOne? Tweet me the reply if you remember it. A photo of yourself in the same shirt is a bonus! No prices other than fame and glory 🙂

Hashtag Jakarta EE #12

Welcome to the twelfth issue of Hashtag Jakarta EE!

This week, I should have been speaking at JavaLand, one of my favorite conferences.

But as you are aware of, this conference was added to the long list of cancelled events this spring.

Being a Developer Advocate normally involves a lot of travel and interacting with people face-to-face. Now that we’re all grounded in one way or the other, I have been exploring the various options for creating video content, either by live-streaming or prerecorded sessions. It is a jungle! The rest of this post describes some of the efforts we have started up this week.

I am super happy with the free Crowdcast channel for JUGs that we were able to set up with funding from Jakarta EE. Make sure to add it to your bookmarks and follow the channel for updates on upcoming events.

This morning I created the Studio Jakarta EE YouTube channel and uploaded the first video, so I can now officially call my self a Youtuber 🙂

At the Eclipse Foundation, we will also start streaming a series of interviews, discussions and live events on the Eclipse Foundation Crowdcast channel.

If you are still hungry for more, take look at the recordings from last year’s Jakarta One LiveStream.

Hashtag Jakarta EE #11

Welcome to the eleventh issue of Hashtag Jakarta EE!

It’s been a special week. But at least, in our industry, we are pretty well equipped and used to remote working. Let’s just cross our fingers and hope that the measures taken will get the situation under control and we can get back to normal as soon as possible.

Supporting the Community

At the end of the week, we launched an initiative sponsored by the Jakarta EE Working Group to enable Java User Groups around the world to stream live events for free using our Crowdcast account. This will be available for at least as long as physical meetups are put on hold due to the Covid-19 situation.

Over to some updates about what is going on in the MicroProfile community.

Push vs Pull

The hangout this Tuesday was in entirety devoted to discussing the Pull vs Push approach for technical alignment with other standardization bodies, such as Jakarta EE. The vote is ongoing and will be closed Tuesday, March 17. Check out the MicroProfile Calendar for details about how to join the MicroProfile hangouts.

The current status of the voting indicates that the decision will be to go for a Pull model. What will this mean for Jakarta EE?

Implications of Pull

The obvious consequence of the Pull model is that if Jakarta EE decides to pull in a MicroProfile specification, it will essentially mean a fork. For those runtimes supporting either MicroProfile or Jakarta EE, but not both, it will be business as usual.

Those supporting both will have the headache of figuring out how to implement this. This will probably not be a hard nut to crack until one, or two of the tines of the fork, start evolving.

A possible Scenario

Let’s say that Jakarta EE decides to pull in MicroProfile Config and create a specification called Jakarta Config. The base package is changed from org.eclipse.microprofile.config to jakarta.config and the specification is added to the Jakarta EE Full and/or Web Profile.

Other Jakarta specifications are now free to reference Jakarta Config and implementations are required to implement it in order to be Jakarta EE Compatible. Products out there supporting both (e.g. OpenLiberty, WildFly, and Payara to mention a few open-source implementations), will now have two configuration options that are more or less identical.

Let’s say, then, that Jakarta Config adds a nifty feature. Should this feature be back-ported to MicroProfile Config? Or should MicroProfile Config be abandoned and Jakarta Config added to the base Jakarta specs required for MicroProfile?

I think these questions need to be addressed somehow, and that it is up to the vendors behind these initiatives to figure out a strategy that is in the best interest of their customers. It is a too easy way out to say that this will self-regulate by the community.

Hashtag Jakarta EE #10

Welcome to the tenth issue of Hashtag Jakarta EE!

Join me in celebrating the 10th issueversity of this series! I can’t believe we’re already at 10.

In the MicroProfile Hangout this week, the discussion around technical alignment with related technologies and standardization efforts (such as Jakarta EE) continued. Two approaches have crystallized themselves and the goal is to come to a decision at the hangout next week (Tuesday, March 10). The models discussed are push and pull.

The Pull Model implies that MicroProfile creates and evolves specifications without regard to downstream consumer requirements (e.g. Jakarta).

With the Push Model, MicroProfile specifications, when mature/stable, are transferred to external organizations (e.g. Jakarta EE).

As I mentioned above, the goal is to settle which approach to go for at the MicroProfile Hangout next week. Make sure to tune in to that one. Refer to the MicroProfile Calendar for details about the call.

The Virus

Due to Covid-19, a large number of events are being canceled. Those I had scheduled to speak at are, Red Hat Summit and IBM Think so far. All of these will be replaced by virtual events.

While virtual events are better than nothing, I don’t think they will ever be able to fully face-to-face events. The hallway discussions and the social benefit of actually meeting someone physically are what makes conferences irreplaceable. Looking forward to continuing to meet you all at the conference circuit later when the dust has settled. Meanwhile, I will participate in virtual events as well as smaller gatherings and meetups where they are possible to arrange.

Hashtag Jakarta EE #9

Welcome to the ninth issue of Hashtag Jakarta EE!

This week, I had the pleasure of speaking at ConFoo in Montreal. It was my second time speaking at this conference. This was the 18th edition and the number of attendees has increased every year. 839 registered attendees this year!

My first talk was a live coding session where I demoed most aspects of Eclipse MicroProfile.

On the second day, I did the Microservice Patterns talk where I go through a list of microservice patterns and show how each of them is implemented with Eclipse MicroProfile.

An interesting observation regarding the strength of the various brands is that when I did a poll at the beginning of both my talks, about 5% had heard about MicroProfile, about 50% about Jakarta EE and 100% had heard about Spring Boot. It should be noted that ConFoo is originally a PHP conference that has extended out to include more technologies, so the audience was not necessarily 100% hardcore server-side Java developers. But still interesting to see how the awareness of Jakarta EE is growing.

To round of wit something sweet; after the conference, we went on a trip to a Sugar shack outside of Montreal.

The favorite on the table I were seated were bacon with maple syrup!

Hashtag Jakarta EE #8

Welcome to the eigth issue of Hashtag Jakarta EE!

This week, I was at Devnexus in Atlanta. This awesome conference organized by the Atlanta Java User Group has established itself as the place to be if you are a Java developer. This year with 2400 attendees and an amazing line-up of world-class speakers.

On the evening the first day of the conference, the Eclipse Foundation hosted a Cloud Native for Java Meetup. More than 100 participants came together for food, drinks and technical discussions around Jakarta EE and Eclipse MicroProfile.

My talk What’s Going on with Jakarta EE was well received by those who attended. I gave an update on Jakarta EE 9 as well as outlining many of the various ways of getting involved.

The Jakarta EE booth was located in the community corner of the exhibition hall together with Apache, OSI, and AdoptOpenJDK. We had a great time there with lots of good discussions.

Hashtag Jakarta EE #7

Welcome to the seventh issue of Hashtag Jakarta EE!

One of the most common questions I get when talking about Jakarta EE is: “How can I help?”. Well, here is a suggestion: The post “Help wanted: improved signature test tool” by Bill Shannon on the Jakarta EE Community mailing list asks for help improving the signature test tool used by the TCK.

In short, what we need help with is to fix the features of this tool to make it possible to either limit the recorded signatures to the API being tested or exclude the signatures for the JDK classes. See the GitHub issue for details.

MicroProfile will produce specs and it is up to others how they adopt or consume them

This week’s MicroProfile Hangout was dedicated to Working Group discussions. The agenda was, as always, set by the participants and the topic this week quickly became technical alignment between MicroProfile and related technologies, such as Jakarta EE. The result of this discussion is summarized by John Clingan in the thread MicroProfile Working Group discussion – Push vs pull on the MicroProfile mailing list. Basically, what this approach means is that MicroProfile will produce specs and it is up to others how they adopt or consume them.

There is an interesting Twitter discussion going on around Quarkus, CDI and the requirements to claim MicroProfile compatibility. This discussion has moved over to various threads on the MicroProfile mailing list. The disagreement within the MicroProfile community is whether the Java EE specifications (JAX-RS, JSON-B, JSON-P, and CDI) are a part of MicroProfile or just referenced APIs. Why this distinction is important is worth a blog post on its own, but the gist of it is that if CDI is a part of the platform, a product cannot be claimed to be compatible with MicroProfile unless the CDI TCK is passed.

For reference, I have included the graphics describing the content of the first (1.0) and the current (3.2) release of MicroProfile below.