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!
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.
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!
I am super excited to announce that October 1st, I will become the first Jakarta EE Developer Advocate at Eclipse Foundation!
So, What’s new? Hasn’t this guy been doing this for years already?
Well, yes, and no. My day job has always been working as a consultant even if I have been fortunate that Cybercom Sweden (my employer of almost 15 years) has given me the freedom to also work on open source projects, community building and speaking at conferences and meetups.
What’s different then?
Even if I have had this flexibility, it has still been part-time work which has rippled into my spare time. It’s only so much a person can do and there are only 24 hours a day. As a full-time Jakarta EE Developer Advocate, I will be able to focus entirely on community outreach around Jakarta EE.
The transition of the Java EE technologies from Oracle to Jakarta EE at Eclipse Foundations has taken a lot longer than anticipated. The community around these technologies has taken a serious hit as a result of that. My primary focus for the first period as Jakarta EE Developer Advocate is to regain the trust and help enable participation of the strong community around Jakarta EE. The timing of establishing this position fits perfectly with the upcoming release of Jakarta EE 8. From that release and forward, it is up to us as a community to bring the technology forward.
I think I have been pretty successful with being vendor-neutral throughout the years. This will not change! Eclipse Foundation is a vendor-neutral organization and I will represent the entire Jakarta EE working group and community as the Jakarta EE Developer Advocate. This is what distinguishes this role from the vendor’s own developer advocates.
I hope to see you all very soon at a conference or meetup near you!
The agreement between the Eclipse Foundation and Oracle regarding rights to Java trademarks has been signed! This is truly an important milestone for Jakarta EE since we will now be able to move forward with Jakarta EE.
One part of the agreement is regarding the use of Java trademarks. The implications for Jakarta EE is that we have to rename the specifications and the specification projects. This work is ongoing and is tracked in our specification renaming board on GitHub. The EE4J PMC has published the following Naming Standard for Jakarta EE Specifications in order to comply with the trademark agreement.
The javax Namespace
The major topic of the agreement is around the use of the javax namespace. The agreement permits Jakarta EE specifications to use the javax namespace as is only. Changes to the API must be made in another namespace.
While the name changes can be considered cosmetic changes, the restrictions on the use of the javax.* namespace come with some technical challenges. For example, how are we going to preserve backwards compatibility for applications written using the javax.* namespace?
The Jakarta EE Specifications Committee has come up with the following guiding principle for Jakarta EE.next:
Maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.
With the restrictions on the use of the javax.* namespace, it is necessary to transition the Jakarta EE specifications to a new namespace. The Jakarta EE Specification Committee has decided that the new namespace will be jakarta.*.
How and when this transition should happen is now the primary decision for the Jakarta EE community to make. There are several possible ways forward and the forum for these discussions is the Jakarta EE Platform mailing list.
Please make sure that you subscribe to the mailing list and join in on the discussion. We hope that we will be able to reach some form of consensus within a month that can be presented to the Specification Committee for approval.
While the restrictions on the use of Java trademarks and the javax.* namespace impose both practical as well as technical challenges, it is also an opportunity to perform some housekeeping.
By renaming the specifications, we can get a uniform, homogeneous naming structure for the specifications that makes more sense and is easier on the tongue than the existing. By having clear and concise names, we may even get rid of the need for abbreviations and acronyms.
The shift from javax.* to jakarta.* opens up for the possibility to differentiate the stable (or legacy) specifications that have played their role from the ones currently being developed.
The SPRING INITIALIZR at https://start.spring.io has been around for a while and is the best way to bootstrap a new Spring Boot application.
So far, there hasn’t been a similar way to bootstrap a new MicroProfile project even if the different vendors have provided starters for their implementations. But the wait is over! The MicroProfile Starter is currently in “Beta”, but works like a charm. Just navigate to https://start.microprofile.io and start generating.
Based on which version of MicroProfile you select, you will get the available implementations that supports that particular version. You have the option of generating examples for the specifications included in the selected version. This is an excellent way to learn how the different technologies work.
Devnexus 2019 is happening in Atlanta next month. This is truly an awesome tech conference run by the Atlanta Java Users Group and I am so happy to be part of it as a speaker for the third time.
My talk this year is a presentation of patterns commonly used in microservice architectures. Each of the patterns will be explained and demoed live using Eclipse MicroProfile.
Another think I look forward to at Devnexus is to meet up with will all the people participating in Jakarta EE that are present at the conference.
The party theme this year is R3, which stand for Reflect, Relax, Recharge and is definitely the place to be to meet all the awesome community members, Java Champions and Groundbreaker Ambassadors present! Everybody will be there, and so should YOU!
There is a limited number of super cool t-shirts exclusively made for this party. One of them could be yours simply by writing a blog post!
This is all very good, excellent actually! When you think about the size of it all, it is actually quite an achievement. We are talking about 7.7 million lines of code! More than 60.000 files and a total of 38 new projects that have been set up at the Eclipse Foundation.
But, as everyone knows, developers are impatient and eager to try out everything new, so there are still a couple of questions that I always get when talking about Jakarta EE:
When can I start developing Jakarta EE applications?
The answer to the first question is: “not yet”. Until the Jakarta EE specification process is finalized, the technologies are still Java™ EE.
The answer to the second question differs a little depending on who you ask, but usually is something in the lines of “I am pretty sure that some of the MicroProfile specs will be integrated into Jakarta EE when they have proven to be useful”.
NO, here is what you should do: Use the power of Java™ EE 8 and combine it with Eclipse MicroProfile.
Many of the application server vendors have added MicroProfile features to their Java™ EE 8 compliant or certified application servers. Examples are Open Liberty, WildFly, Payara and Apache TomEE. See the respective vendor’s documentation for which versions they have included.
I have put together a simple application called Jakarta EE Duke to demonstrate how to do this. The application uses the @ConfigProperty annotation from MicroProfile Config to configure a message as well as the new @Email annotation from Bean Validation 2.0, which came with Java™ EE 8 to validate input.
While this example is extremely simple, it does indicate how you can combine the full power of Java™ EE 8 with the lightweight APIs of MicroProfile to implement cloud-native microservices using Java™ technology.