One of the goals for the Jakarta EE Platform project is to define a predictable way the Jakarta EE specifications are aligned with Java SE. For example: Which Java SE version should Jakarta EE 10 require? This is one of the questions currently being discussed on the weekly Jakarta EE Platform calls. We have narrowed it down to three options that are currently being voted on:
Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+ Java SE 11 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.
Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+ Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.
Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+ Java SE 17 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.
Everyone is encouraged to chime in on the mailing list with their opinion. Remember to mark the committer flag in your vote to true only if you are a committer on the Jakarta EE Platform project.
The intention of the Jakarta EE Core Profile specification is to target smaller runtimes and allow them to be certified as Jakarta EE compatible products. The set of Jakarta EE specifications that will be included in the profile has not been defined yet, but here is the latest suggestion for how it could potentially look like.
The Jakarta EE Platform project does not rest on its laurels! Vivid discussions are going in the weekly platform calls as well as on the mailing lists. Read the minutes from the platform calls to keep informed in case you are not able to join the calls.
Talking about keeping up-to-date, I will be speaking at J4K this week. My talk, Jakarta EE Core Profile – A Slimmer Jakarta EE, is about the Jakarta EE Core Profile which you may say is very much a work-in-progress. This talk will give you the latest status update as well as pointers to how to contribute and influence the direction of the specification.
I am extremely happy to see that Hibernate ORM 5.5.0 is now certified as a compatible implementation of Jakarta Persistence! They have passed the TCKs for both Jakarta Persistence 2.2 and Jakarta Persistence 3.0 which means that they are aligned with both Jakarta EE8 and Jakarta EE 9 supporting both the jakarta.* namespace as well as javax.*. This is an important milestone. Provides a migration path for all those applications out there using Hibernate ORM for persistence.
The Call for Proposals for EclipseCon 2021 ends on June 15, so there is still time for you to submit your Jakarta EE talk to have a chance of being a speaker!
The planning for JakartaOne LiveStream 2021 has just started. Mark December 7, 2021 in your calendar today. More details and dates for the Call For Paper will be announced shortly. Stay tuned!
But, we don’t rest there. The work with Jakarta EE 10 is progressing as well. The creation- and plan review for Jakarta EE Core Profile 10 was approved this week by the Jakarta EE Specification Committee. We have also started the issues for defining the scope of Jakarta EE Web Profile 10 and Jakarta EE Platform 10. Plan reviews of these are expected to be initiated shortly.
The project proposal for Jakarta Config is being processed. Since it is a project that will produce a specification under the Jakarta EE Specification Process (JESP), a creation review by the specification committee is required. This review ballot is ongoing and will end this week. Community members are encouraged to chime in and place their (non-binding) vote.
In the Jakarta EE Platform call this week, we decided to ask the specification projects for feedback on whether October 15, 2021 is an achievable date for having their specifications ready for release. So far, the feedback has been positive. It is great to see that the specifications are moving forward again. The Jakarta EE 9 release with the associated namespace change from javax.* to jakarta.* may very well prove to be the tap on the bottle that got the ketchup flowing.
The Eclipse Cargo Tracker is a fantastic example of an end-to-end Jakarta EE application that showcases core Jakarta EE technologies. Thanks to Scaleforce and Jelastic for providing resources to deploy the demo application to the cloud.
Let’s look at Jakarta EE 10! By filtering on the EE10 label in our GitHub issue tracker, you will find the list of topics currently under discussion. I would like to highlight a couple of the issues.
Jakarta EE 10 Direction Statement (#352) lists focus areas that we are working on in order to come up with a proper roadmap for the platform. The platform team has been tasked by the Jakarta EE Steering Committee to produce a statement of direction for the steering committee meeting on May 11, 2021. I think we are in pretty good shape, but it will most certainly be refined more in the platform call a couple of hours before the steering committee gathers.
The Jakarta EE 9.1 release is coming up shortly. The release review ballot for ratification of the specification will start this week. A special detail regarding this release is that there will be at least three, possibly four, compatible implementations used for ratification. Eclipse GlassFish, OpenLiberty, and WildFly have submitted their Compatibility Certification Requests already. We hope that Apache TomeEE will make it as well!
The plan reviews for individual specifications are ongoing. You can follow their progress by checking out the pull requests labeled plan review. As they are approved, they will pop up on their respective page under Jakarta EE Specifications.
I want to remind you about the Jakarta EE Specifications Calendar, where the specification projects are encouraged to publish there calls in order to allow more people to join the discussions.
These CCRs will be used in the ratification of the final Jakarta EE 9.1 specification. This time, we are hoping for additional compatible implementations to be a part of the material reviewed by the Jakarta EE Specification Committee. Since we plan to initiate the release review ballot on April 30, it is time to start preparing the Compatibility Certification Requests by following these steps outlined by the Jakarta EE TCK project lead Scott Marlow.
The 2021 Jakarta EE Developer Survey is still running. If you haven’t answered it yet, I encourage you to take this opportunity to provide input to the direction of Jakarta EE. It only takes a couple of minutes to answer.
The CFP for EclipseCon 2021 is open. Don’t hesitate, submit your Jakarta EE talk today! If you are new to speaking, or unsure what to talk about, ask someone in the community to team up with you and do a joint talk!
Eclipse GlassFish 6.1.0.RC1 passes the Jakarta EE 9.1 TCK and is available for download. The TCK project is in the process of wrapping up everything for the release. We plan to initiate the review ballot for the Jakarta EE 9.1 specifications on April 30, which means that the artifacts will be released to Maven Central on May 14th. This is a soft launch as we have been doing the last couple of releases, so the official release date with all the marketing splash around it will be May 25th.
Worth noting for this release is that it looks like GlassFish won’t be alone as a compatible implementation when the specification is ratified. A number of vendors are working hard to have their implementations available along with Glassfish for the release review ballot.
I guess it is safe to say that we were blown away by the number of detailed plans and outlines submitted as pull requests to the Jakarta EE Specifications repository. Just take a look at the list below grouped by major and minor updates to the specifications.
Major updates Jakarta Authentication 4.0 Jakarta Authorization 3.0 Jakarta Concurrency 3.0 Jakarta Expression Language 5.0 Jakarta Faces 4.0 Jakarta JSON Binding 3.0 Jakarta RESTful Web Services 4.0 Jakarta Security 3.0 Jakarta Servlet 6.0 Jakarta SOAP with Attachments 3.0 Jakarta Standard Tag Library 3.0 Jakarta XML Binding 4.0 Jakarta XML Web Services 4.0
Minor updates Jakarta Activation 2.1 Jakarta Connectors 2.1 Jakarta JSON Processing 2.1 Jakarta Mail 2.1 Jakarta MVC 2.1 Jakarta Persistence 3.1 Jakarta Server Pages 3.1 Jakarta WebSocket 2.1
I can’t wait to dive into the details of these plans as they progress through the plan reviews stipulated by the Jakarta EE Specifiation Process. Take a look at the JESP Guide for a simple walk-through of the process.
One of the most exciting things that happened in the Jakarta EE space this week is that the Jakarta EE Platform project decided to start working on a new Jakarta EE Core Profile. The Pull Request to start the process of creation- and plan reviews from the Jakarta EE Specification Committee has been created. I will post more when work progresses.
If you are involved in a Jakarta EE specification project, 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. Refer to the JESP Guide for useful pointers and links to help you navigate the Jakarta EE Specification Process (JESP).
The 2021 Jakarta EE Developer Survey is now open. This has become an annual tradition and is your chance to influence the direction of the Jakarta EE working group. It takes less than 8 minutes to complete.