Jakarta EE 9.1 is on track for the mid-May release. GlassFish 6.1 now passes the TCK and a release candidate will be made available this week.
Meanwhile, the work with planning for the next Jakarta EE release goes on. We are getting very close to be proposing a new profile in addition to the current Full Platform and Web Profile. This profile will most likely be called Jakarta EE Core Profile and be specifically targeted at smaller runtimes for microservices and capable of producing minimal cloud-native images.
For the other component specifications, please do remember to submit a request for plan review by April 15. This will make it possible for the platform team to get an overview, and plan for the content of the next release. We will also shortly invite all specification projects to participate in a community meeting. Stay tuned and look out for the invite that will be socialized on all appropriate channels when we have nailed down the details.
I will encourage specification projects to open calls to help drive their work forward. Since we currently don’t meet in the hallways at events and conferences, these meetings are an important way of having discussions in realtime. Makes life on the mailing lists so much easier afterward…
We have created the Specifications Calendar specifically for this purpose. All the project leads of Jakarta EE specification projects have been given permissions to add events to the calendar.
It looks like Jakarta EE 9.1 may be delivered sometime in May. The Jakarta EE Platform project discussed the possibility for a release date in mid-May at this week’s platform call. There are still a couple of details to be sorted out before a final date can be announced. Stay tuned for updates.
The platform team has also started discussions regarding adding a profile to the next release of Jakarta EE. This discussion is currently going on the mailing list.
On Wednesday, March 31, I am giving a short keynote at JakartaOne LivesStream – Russian. What’s interesting about this one is that it will be in Russian. Since I, unfortunately, don’t speak Russian, the organizers have been very helpful in translating my talk and adding a Russian audio track. I hope you will enjoy it!
If you still can’t get enough of Jakarta EE, please don’t hesitate to contact us if you want to host us at your local JUG or Meetup. We still offer free use of Crowdcast for JUGs for streaming your events.
Tanja and I are always eager to visit you and talk about Jakarta EE. We have visited a lot of JUGs in the last 6 months. And we want to visit more. If you want your JUG on this list, you know what to do. Contact us!
At the end, I want to point you to the new Adoptium web site that was just recently launched. This is your one stop shop to download prebuilt OpenJDK binaries for free.
$ java -version
openjdk version "16" 2021-03-16
OpenJDK Runtime Environment AdoptOpenJDK (build 16+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 16+36, mixed mode, sharing)
Java 16 contains a lot of goodies for us, so go ahead and download it to give it a try. or me, the most important feature in JDK 16 is Records (JEP 395). The reason for this is that it reduces the amount of boilerplate code needed. The possibility to write record Point(int x, int y) { } rather than the entire class listed below really appeals to me. The code never written is the best code, as it is guaranteed not to contain any bugs.
class Point {
private final int x;
private final int y;
Point(int x, int y) {
this.x = x;
this.y = y;
}
int x() { return x; }
int y() { return y; }
public boolean equals(Object o) {
if (!(o instanceof Point)) return false;
Point other = (Point) o;
return other.x == x && other.y = y;
}
public int hashCode() {
return Objects.hash(x, y);
}
public String toString() {
return String.format("Point[x=%d, y=%d]", x, y);
}
}
I participated in three sessions at JavaLand 2021. First out on Tuesday was Jakarta EE 9 and Beyond which was followed by a Jakarta EE Panel. On Wednesday, it was time for Mobile Java Web Applications with MVC and OpenDDR where I was presenting together with Werner Keil. Despite some technical difficulties with the streaming platform on Tuesday, the conference went smoothly. Let’s hope that we will be back in Phantasialand for next year’s edition!
Work with Jakarta EE 9.1 continues. An agenda item for the platform call this week is to set a release date for Jakarta EE 9.1. We have also started the work by looking ahead towards the next releases. Currently, there are some interesting discussions happening on the Jakarta EE Platform mailing list regarding the definition of new profile specifications.
Also, note that the platform team requests plan reviews from the specification projects to be ready for ballot by April 15 in order to be a candidate for the next release. If you are unsure what to do for a plan review, check out the JESP Guide.
We have tried to keep the overhead to a minimum with the Eclipse Foundation Specification Process (EFSP). Compared to other specification processes, it is pretty lightweight. Both the Jakarta EE Specification Process (JESP) and the MicroProfile Specification Process (MPSP) adopts the EFSP with a couple of additions that are so similar that they are barely distinguishable.
While knowing the process is good, every developer does not need to know the nitty-gritty details. That is why we have created a step-by-step guide to help developers on Jakarta EE specification projects with the steps of the JESP. Take a look at the JESP Guide to check it out!
JavaLand 2021 is happening this week! We have a lot of great content and community activities to look forward to. Here is a pointer to some of the talks on Wednesday, March 16 by Emily Jiang, Ondrej Mihalyi, and yours truly.
On Wednesday, March 17, I have a joint talk with Werner Keil where we use Jakarta MVC in one of the demos. Directly after, Emily Jiang and Ed Burns show how to port an application from Spring Boot to MicroProfile.
One of the major changes introduced with Jakarta EE over how it used to be is that the TCKs are available for free to anyone that wants to certify their implementation. I described how to do this in Compatible Implementations.
In parallel with the work on Jakarta EE 9.1, the individual specifications plans for future releases. Some of the teams are setting up ad-hoc or regular calls in addition to discussing on the mailing lists. In order to have a common calendar to keep track of these calls, we have created the Jakarta EE Specifications Calendar. We encourage the teams to publish their meetings on this calendar. This will make it easier for the community to attend calls they are interested in.
Tanja and I have been touring JUGs over the last couple of months. So far, we have visited JUGs (virtually) in India, South Africa, Sweden, Serbia, the USA, Poland, Germany, and Spain. And we don’t want to stop there! Please reach out to us if you want us to visit YOUR JUG or Meetup!
It is the end of February already, and the release date for Jakarta EE 9.1 is approaching quickly. A release candidate of the API is available in Maven Central. The current activities are around updating the compatible implementations to pass the TCK on JDK 11.
In order to make it to the proposed release date of March 25, the release review must start at the latest on March 11. That means that there are less than two weeks to get Eclipse GlassFish to pass the TCK on JDK 11.
Beyond Jakarta EE 9.1
Looking ahead, discussions around the next release have started in the Jakarta EE Platform Project. To be able to define the scope of the next release, we need input from the component specifications. Plan reviews are due on April 15, 2021 to be considered as candidates for the next release of Jakarta EE. The plan submitted for review must be possible to implement within 6 months. Which in turn means that we are looking at a Jakarta EE release in October, 2021.
As I mentioned last week, the release plan for Jakarta EE 9.1 has been published. The target release date is the end of March 2021. GlassFish 6.1 now compiles and runs on Java SE 11, and the work with getting it to pass the TCK goes on.
The Jakarta EE Platform team has also started to prepare for the next Jakarta EE release after 9.1. At them moment, we are collecting input from the various specification projects to be able to define the content of this release. The deadline for starting plan review for the next Jakarta EE release is April 15, 2021. Make sure to check the minutes for updates. We encourage specification projects to join the Platform calls and give an update on their plans. The details for the platform calls can be found in the Jakarta EE Platform Calendar.
The JUG Leaders Summit and Devnexus took place this week. Devnexus is an awesome conference to visit, and the virtual edition this year was no exception. Let’s just hope that we will be back in Atlanta for next year’s edition.
There is only one more stop planned on the Jakarta EE Virtual Tour, and that is Chicago JUG on February 25. We really enjoy giving these talks, so please reach out if you are interested in hosting us at your JUG or MeetUp.
Jfokus 2021 happened this week. I was involved as a stage host in this year’s edition which was virtual. Next year, I hope to be back in Stockholm for Jfokus 2022.
On Tuesday, the JUG Leaders Summit takes place as a prequel to Devnexus. I look very much forward to meeting many of my fellow JUG leaders at the summit.
The release plan for Jakarta EE 9.1 has been published. The target release date is the end of March 2021. Follow the progress with our GitHub Project Board. While we are working full speed on completing Jakarta EE 9.1, we are also starting to look ahead a little. In the Platform Call this week, we decided to set a deadline for specifications to start their plan reviews in order to be a part of the next release. This deadline is April 15, 2021. Make sure to check the minutes from the platform calls if you are not able to attend a call. I try to publish the minutes as soon as possible after the call. The platform calls happen every Tuesday at 11:00 AM EST and the details can be found in the Jakarta EE Platform Calendar.
This was the weekend of Fosdem. I had a Jakarta EE talk on Saturday in the Foojay devroom. The talk was recorded and I was looking forward to wearing my new, nice T-shirt on the video during the Q&A. A last-minute decision by the organizers turned this into a chat Q&A, which turned out to work very well. The Fosdem audience is awesome!
I also visited the Eclipse Foundation stand. Do come by if you happen to read this before the conference is over. You can win a nice Eclipse Foundation hoodie!
Jfokus 2021 is happening on Tuesday, February 9. I will be hosting Track D together with Grace Jansen. There will be talks by Paul Bakker, Jonathan Giles, and Dmitry Alexsandrov during our time as hosts. I encourage you to visit us, and of course, do check out the other tracks as well.
As you probably are aware, the concept of a single reference implementation (RI) to prove that a specification is implementable does not exist in Jakarta EE. The Jakarta EE Specification Process (JESP) mandates at least one compatible implementation (CI), but preferably as many as possible.
An unintentionally hidden “secret” is how easy it is to get your compatible implementation listed on a specification page. I hope this blog post will clarify the process and make it a little less “hidden“. We are looking into how we can simplify this even further by automating some of the steps, but this is how it looks like right now.
TLDR;
Step 1. Pass the TCK and publish the results Step 2: File a Certification Request Step 3. Submit a PR to get listed (we are looking at ways to automate this step)
Step 1. Pass the TCK and publish the results
The prerequisite is that you pass the TCK for the specification you implement. The TCK may be downloaded from the specification page and is specific to a version of the specification.
The next step is to publish the TCK results. This is the heart of self-certification. You run the TCK and publish the results yourself. This means that you don’t have to rely on others to run the tests for you. And by publishing the results, you take responsibility for the correctness of the results.
TCK Results
For some examples of how to publish the TCK results, check out the results for Eclipse Yasson 2.0.0 (implements Jakarta JSON Binding 2.0), Weld 4.0.0 (implements Jakarta CDI 3.0), and Eclipse Krazo 2.0.0 (implements Jakarta MVC 2.0).
After publishing the TCK results, the only thing you need to do is to send an email to tck@eclipse.org to make the Eclipse Foundation aware that you have passed the TCK.
Step 2. File Certification Request
In order to get listed on a specification’s page under on jakarta.ee/specifications as a compatible implementation, the next thing you need to do is to file a certification request in the specification’s issue tracker.
Certification
A certification request needs to follow a specific template to provide the necessary information. I have added the source for the template here:
- [ ] Organization Name ("Organization") and, if applicable, URL:
// Add here
- [ ] Product Name, Version and download URL (if applicable):
// Add here
- [ ] Specification Name, Version and download URL:
// Add here
- [ ] TCK Version, digital SHA-256 fingerprint and download URL:
// Add here
- [ ] Public URL of TCK Results Summary:
// Add here
- [ ] Any Additional Specification Certification Requirements:
// Add here
- [ ] Java runtime used to run the implementation:
// Add here
- [ ] Summary of the information for the certification environment, operating system, cloud, ...:
// Add here
- [ ] By checking this box I acknowledge that the Organization I represent accepts the terms of the [EFTL](https://www.eclipse.org/legal/tck.php).
- [ ] By checking this box I attest that all TCK requirements have been met, including any compatibility rules.
When a specification team receives a certification request, they will add the accepted label after verifying the contents of the request. See the certification requests for Eclipse Yasson 2.0.0, Weld 4.0.0, and Eclipse Krazo 2.0.0 for examples of certification requests.
Step 3. Submit a PR to get listed
When the certification request has been approved, the last step is to submit a Pull Request to the specifications repository where you add your implementation to the list of compatible implementations for the specification.
Pull Request
The file you should update is the _index.md file located in the version sub-directory of the specification you are implementing. For example, to add a new compatible implementation called OpenKangaroo 1.0.0 to the Jakarta Wombat specification, I would add the line marked with (+) below:
That’s it! We are looking into automating as much as possible of this process to make it as easy as possible while maintaining the necessary control mechanisms. Until we get there, the three steps described in this post are what you need to do.
Step 1. Pass the TCK and publish the results Step 2: File a Certification Request Step 3. Submit a PR to get listed (we are looking at ways to automate this step)
Please don’t hesitate to reach out to us on one of our mailing lists if you have questions.
