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.
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.
On the fun side, I was made aware that my shoutout for the Hashtag series may be a little confusing as you can see in my conversation with Ronnie Zolverda.
I didn’t want to use #5 to indicate number 5 since Twitter would then interpret the hashtag (#) as if I were tagging the number 5. Also interesting that nobody reacted on the first 4 posts…
From this week on, I will tweet that “Hashtag Jakarta EE number X is out!” to avoid confusion in the future 🙂
So, over to the technical side. Gunnar Morling referred me to a recent article of his where he describes how to use the JDK Flight Recorder to monitor REST APIs.
We didn’t have any Jakarta Tech Talks or Update calls this week, but the work with Jakarta EE 9 proceeds as planned. The status is best followed by checking out the project board. We have now passed the deadline for individual component release plans. These are Java Activation Framework 2.0 and Jakarta Enterprise Beans 4.0. The rest will follow the release plan for the full platform.
So far, there are two proposals on the table; a joint working group or two separate working groups. While the structure of the working group(s) is important, another aspect is the technical alignment of Jakarta EE and MicroProfile. A couple of weeks ago David Belvins put forward a couple of proposals to bootstrap the discussions. A third proposal was presented by Steve Millidge where he proposes that profiles in Jakarta EE are promoted to individual brands and that MicroProfile becomes a profile of Jakarta EE. Interesting thoughts!
This weekend, I attended my first FOSDEM. This is a free event that takes place in Brussels every year. It is quite an experience with fully packed rooms and crowded corridors. Sessions are short (25 mins) and focused. Absolutely a recommendation!
We’re on a roll here! I can’t believe it is already four weeks since I started this series!
Stay tuned for announcements about Jakarta MVC!
A little on the side of Jakarta EE, but still related is that the MVC 1.0 specification (JSR 371) is finally final! We have been working with this for a long time, and special thanks to Christian for his work in getting the release out the door! Without him, I doubt there would be a release of MVC!
So, why isn’t MVC already moved over to the Eclipse Foundation and Jakarta EE? The short answer to that is that we wanted to finish the first release under the JCP in order to have a released project to transfer. We have already transferred Krazo, the reference implementation and the plan is to start the transfer of the specification and the TCK shortly. Stay tuned for announcements about Jakarta MVC!
Jakarta EE 9 is moving forward with great progress. The status of all the work is tracked on the Jakarta EE 9 tracking board. If you are involved in one of the specifications in the Plan Review column, you are encouraged to take a look and see how you can help move these specifications forward to the In Progress column. Instructions can be found in notes at the top of the columns.
Most of this week was spent at the Eclipse Foundation office in Ottawa. It is great to have the opportunity to meet the people I work with daily in person once in a while.
On Tuesday, January 14, there was an off-week MicroProfile Hangout dedicated to the discussions around the Working Group proposals for MicroProfile. The hangout was pretty well attended with the usual suspects doing most of the talking. See the presentation and meeting minutes for more details. The session was even recorded.
Attending conferences like CodeMash that are not entirely Java-centric is a great reminder that outside our bubble, most developers haven’t heard about Jakarta EE or MicroProfile at all!
It is both challenging and rewarding to give a talk where you are not preaching to the choir. I encourage you all to do this more often. This is how we spread the message! This is how we grow our community!
In the Jakarta EE space, we started the week with an EE4J PMC meeting followed by the Jakarta EE Steering- and Specification committees. The most important agenda item discussed is the ongoing ballot for approval of the Jakarta EE 9 release plan in the Specification Committee. You can follow the ongoing ballot on the Jakarta EE Specification Committee mailing list.
At the end of last year, the Java EE Guardians completed their rebranding to become the Jakarta EE Ambassadors. I am really happy that I was able to help in the process of getting the new logo created. This is the first approved usage of the Jakarta EE brand and logo outside of the Jakarta EE Working Group. A milestone in itself!
For a while now, I have been thinking of posting more regular updates about stuff going on in the Jakarta EE community. Kind of what Josh Long does with his “This Week in Spring” series. Being a big fan of Josh and the work he is doing in the community, I am not ashamed of copying him.
The goal is weekly updates, but being realistic I leave out the cadence from the title. So welcome to the first issue of Hashtag Jakarta EE!
The year 2020 is still young and pristine, most members enjoying a well-deserved vacation after a busy 2019.
It has been a lot of talk about processes in the Jakarta and MicroProfile community lately, so I just want to remind us all about this item from the Agile Manifesto.
Individuals and interactions over processes and tools.
That said, some process is needed. Especially for work with specifications. In this post, I explain the Jakarta EE Specification Process and also think aloud about how the same principles could be applied to Eclipse MicroProfile.
The Jakarta EE Specification Process (JESP) is derived from the Foundation Specification Process (EFSP). The short version is that it specifies how long the voting periods (ballots) are for the various reviews:
Creation Review: 7 days
Plan Review: 7 days
Progress Review: 14 days
Release Review: 14 days
Service Release Review: 14 days
The entire process is visualized in the figure below.
So, how fast can you develop a specification using the JESP? Well, you will need to come up with a specification project proposal and submit it for review. This review may take up to 7 days to be finalized.
The next step is to present the release plan for the Jakarta EE Specification Committee for a Plan Review. This step is optional and meant as a means for the project to secure that you are on the right track. Let’s say we opt-in for this review which means another 7 days, i.e. 14 in total so far.
When your specification is ready to be released, you will submit it for a release review. This will take 14 days to complete and may run in parallel with the ratification by the Jakarta EE Specification Committee. The total amount of days in review for your specification will then be 28 days.
Without the plan review, we are looking at 21 days which is exactly the same as for any project following the Eclipse Development Process (EDP). Which applies to the e.g. the Eclipse MicroProfile project.
The difference between the governance model of Jakarta EE and Eclipse MicroProfile is that Jakarta EE is a working group and has a specification process in place for capturing the intellectual property before a specification is released. Whereas Eclipse MicroProfile is a standard Eclipse Foundation project with an ad-hoc specification process. As an Eclipse Foundation project, the project name has to be prefixed with Eclipse. As a working group, this restriction does not apply.
In the table below, I have summarized some of the similarities and differences and even taken the liberty to draw up how it could look like if a MicroProfile working group with its own specification process was established.
Eclipse MicroProfile (as a project)
MicroProfile (as a working group)
Eclipse MicroProfile [spec]
Specs Consumable by Jakarta EE
Specs Consumable by Eclipse MicroProfile
(*) Thinking aloud: MicroProfile Specification Process (MSP)
The MicroProfile Specification Process could be as simple as this: Adopt the EFSP with the following voting periods (ballots): (…still thinking aloud…)
Creation Review: 7 days (as today according to the EDP)
Plan Review: 7 days (or optional as today)
Progress Review: 7 days
Release Review: 14 days
Service Release Review: 14 days
To sum up, I think the JESP has captured the essence of “Individuals and interactions over processes and tools” by being as lightweight as possible while still protecting everyone involved.
It’s been a week since I started as the Jakarta EE Developer Advocate at the Eclipse Foundation!
As you may have noticed, I am involved in almost any committee around Jakarta EE and enterprise Java in general and my new role has some implications for these engagements. I have listed them below and tried to give a reasonable explanation for each of them.
I have been a member of the EE4J PMC since its inception back in 2017, and for practical reasons served as the PMC Lead the entire time. According to the charter, we are supposed to rotate the leadership among the non-foundation staff members of the PMC. In order to minimize overhead, the PMC decided to stick with me as the lead until otherwise decided.
If the PMC wants me to continue in the PMC Lead position, the “non-Foundation staff” phrase will have to be removed from the charter. This has been put on the agenda for the PMC meeting on November 5th, so then we will know…
Jakarta EE Working Group Steering Committee
I have withdrawn from my elected Committer Representative seat in the Steering Group as this seat should not be held by anyone from the Eclipse Foundation. This position is currently up for election (hint hint: if you want to be involved, nominate yourself…).
Jakarta EE Working Group Specification Committee
The position I have in the Specification Committee is the PMC Representative. It is up to the PMC whether I should continue or withdraw. This will also be handled at the next PMC meeting on November 5th.
Java Community Process (JCP) Executive Committee
I have withdrawn from my Associate Seat at the JCP since the Eclipse Foundation is already on the committee. However, I will still be lurking around here as I will be the alternate representative for the Eclipse Foundation.
The JCP Elections have started. Remember to cast your vote!