Time for this week’s cake, or pie (chart) to be specific… The current status for Jakarta EE 9 is that ten specifications have been approved, two ballots are ongoing and five are almost ready for ballot.
The only specifications that have not created a Pull Request yet are:
The list is getting shorter! If you are involved in any of these, please do go forward with creating the pull requests. They can be created as draft PRs and be updated along the way up to being ready for ballot. There is absolutely no reason to wait until everything is ready!
Java 15 is available. You can download it wherever you usually get your JDK, for example at AdoptOpenJDK. Check out this blog and video by Markus Karg where he talks about all the changes in the Java language since Java 7.
The new date for JakartaOne LiveStream is December 8, 2020! The Call-for-paper will close on October 1st, so make sure you submit your talk.
It is a pleasure to welcome MicroProfile as a Working Group at the Eclipse Foundation! It has been a long process, but we are finally getting there. Check out the draft charter. It is still in proposal state, but expect more news to come about this shortly.
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.
Background
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.
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.
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.
The discussions regarding establishing a working group for MicroProfile, mentioned in Hashtag Jakarta EE#1 and #3, continue with weekly MicroProfile hangouts as well as being a recurring topic in the Jakarta EE Steering Committee.
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!
This demo-heavy talk was well received. There has been a steady increase of participants in our JUG over the last year, a strong indication for the continued popularity of Java.
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.
We even had a Jakarta EE Community Update Call where we talked about Jakarta EE 9, the Jakartification of the specification documents as well as the 2020 program and budget.
In the blog space, there is a lot being written about Jakarta EE. I will point to a couple of posts here. Will Lyons summarises The Jakarta EE 8 Community Retrospective and you can read about the approval of the Jakarta EE 9 release plan in Mike Milinkovich’ post Moving Forward with Jakarta EE 9,
This week, I have been in Sandusky, Ohio for CodeMash. This awesome conference is organized by an Ohio Non-Profit Organization and is held at the Kalahari resort in Sandusky, Ohio.
In addition to meeting a bunch of awesome people, I had a talk about Eclipse MicroProfile.
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.
At the end of last year, a release plan for Jakarta EE 9 was made available by the Jakarta EE Platform Project. The work with this release will start up again next week with weekly calls. These calls are open for anyone. The details can be found in the EE4J PMC Calendar.
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.
https://agilemanifesto.org/
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.
Eclipse Foundation Specification Process (EFSP)
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.
Jakarta EE
Eclipse MicroProfile (as a project)
MicroProfile (as a working group)
Specification Process
JESP
no
MSP (*)
Development Process
EDP
EDP
EDP
Release Review
14 days
14 days
14 days
Ratification
yes
no
yes
Working Group
yes
no
yes
Project Names
Jakarta [spec]
Eclipse MicroProfile [spec]
MicroProfile [spec]
Specs Consumable by Jakarta EE
yes
no
yes
Specs Consumable by Eclipse MicroProfile
yes
yes
yes
(*) 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.
I am on my way back home from this year’s Oracle CodeOne. As always, this week is so filled with content and activities that it just flies by.
In previous years, I have always had the sort of empty feeling on Thursday (the last day of the conference); the exhibition hall and Groundbreakers Hub is packed away, lunch in the hallways, lots of people walking around with luggage just catching a couple of sessions before heading home.
This year was different. As Ed Burns said in the talk he held together with Phillip Krüger that he found Thursday to be the best day of the conference, to be able to just attend sessions without all the other distractions. And I agree! This year, I listened to great talks from 9 in the morning until 15 in the afternoon with only 15 min breaks between the sessions. No distractions, other than the usual short hallway discussions between the sessions.
and
Jakarta EE 8 was launched the week before CodeOne. Another important milestone for the community! We had a lot of great talks, BOFs and hallway discussions.
The general impression of this edition of CodeOne is that it was smaller than last year. Both in the number of attendees, but also the number of exhibitors. The community spirit, however, was as strong as always!
