If you haven’t done so yet, I want to remind you of the JakartaOne Livestream 2021 Call for Papers. The CFP closes on September 15, so there is still time to have a chance of speaking to a global audience in the third edition of this annual event.
As I mentioned last week, the release plan for Jakarta EE 10 Platform and Web Profile has been approved and published with a target release date of Q1, 2022. It is expected that details around the plan for Jakarta EE Core Profile will be announced next week. Stay tuned for updates!
According to the plan, Jakarta EE 10 Platform and Web Profile is targeting a release in Q1, 2022. This is a little less than a year after Jakarta EE 9.1 (May 2021). In order to make this happen, the individual specifications that the Jakarta EE Platform and Web Profile specifications are based on must start their release process some time in advance of the proposed release date.
October 15, 2021, has previously been communicated as a target date for initiating release reviews for the specifications. The experience from the Jakarta EE 9 and 9.1 releases indicates that this is a reasonable time to start the release reviews to be able to finalize the Platform and Web Profile releases for Jakarta EE 10 in Q1.
So what about Jakarta EE Core Profile? Will it be released at the same time as the Platform and Web Profile? Well, it is possible, but unlikely. It depends on the progress of the CDI Lite specifications and maybe also Jakarta Config. The platform project will propose a release plan for Jakarta EE Core profile shortly. Join the weekly Jakarta EE Platform calls on Tuesdays 11:00 AM ET to get the latest information first and contribute to the progress. you find the details in the Jakarta EE Specifications public calendar.
I want to remind you again to submit your abstracts to the JakartaOne Livestream CFP. The Call for Paper is open until September 15, but don’t wait until the last minute! You are more likely to be accepted if you submit early, and often…
I’m out on vacation these weeks, so I will keep it short this time. The work on the Jakarta EE 10 plan continues, and will (hopefully) be completed in the platform call in the coming week. Even if I am out of office, the Jakarta EE Platform project goes on!
Last week’s platform call was devoted entirely to the Jakarta EE 10 release plan. The platform team is in agreement, and only a last brushup is needed before the plan is submitted for plan review by the Jakarta EE Specification Committee.
As expected from the discussion around adding Jakarta MVC to the Jakarta EE Web Profile, it looks like MVC will continue as an independent specification for a while longer. The reasoning behind this decision is that most application server vendors would like to see more adoption before adding it to the platform. It is kind of a chicken-and-egg situation as inclusion in the platform would most likely result in far more adoption than as it is today. The good news is that Eclipse Krazo is certified as a compatible implementation for runtimes based on both Eclipse Jersey and RESTEasy.
In addition to this, Eclipse GlassFish 6.2.0 is also a certified compatible implementation of Jakarta MVC, so if you’re using this version of GlassFish, no configuration is needed. Just go ahead and create your MVC applications.
The Call-for-Paper for the third edition of JakartaOne Livestream is open. It is open until September 15, but don’t wait until the last minute. You are more likely to be accepted if you submit early…
One of the goals the Jakarta EE platform project is working towards is to create some sort of predictability regarding Java SE with future Jakarta EE releases. It seems that we are approaching something that looks like a strategy regarding this goal.
As previously announced, Jakarta EE 10 will be based on Java SE 11. That means that the specification projects will be able to use Java SE 11 language features in their APIs.
The TCK will be possible to run with any version from 11 and above.
For Jakarta EE 11, the Java SE version will be raised to the next LTS release, which will be Java SE 17. And so on…
What this means for the individual component specification teams, is that they can embrace Java SE language features of the version supported by the platform they plan to target. An example:
The specification Jakarta Wombat 1.1 use Java SE 11 language features and target Jakarta EE 10 while Jakarta Wombat 1.2 use Java SE 17 language features (e.g. Records) and thus target Jakarta EE 11 An implementation of Jakarta Wombat, e.g. Possum can use Java SE 17 features both for Possum 1.0 which implements Jakarta Wombat 1.1, and Possum 2.0 which implements Jakarta Wombat 1.2.
The release plan for Jakarta EE 10 is out for review by the Jakarta EE platform project. Hopefully, we will be able to wrap up the discussions in the platform call on Tuesday, and propose this plan for review by the Jakarta EE specification committee.
Earlier this year, I participated in the Foojay Virtual Tour with a talk at KnoxJava JUG. For the upcoming Virtual Foojay OpenJDK 17+ JUG Tour, I have a new talk called Leveraging OpenJDK 17 features with Jakarta EE. If you would like to hear about this in your JUG, do follow the instruction on foojay.io to sign up.
Last week we hosted the Jakarta EE Update call. If you missed it, don’t despair as it was recorded. As usual, it will be cut into smaller themed pieces and published on the Jakarta EE YouTube channel.
The Jakarta EE Platform project has stated a clarification regarding the Java SE level for Jakarta EE 10. The component specifications are recommended, not recommended to compile their API jar files to Java SE 11. That means that they can compile to lower Java SE levels if it fits them better. The recommendation, however, is still to compile to Java SE 11 using the --release option to the compiler. Exemplified here by the maven compiler plugin configuration.
The topic of release cadence and time-based vs feature-based continues. I suspect this to be the major discussion point in the platform call next week. One of the questions that are being discussed is whether to tie the roadmap and release cadence to the Java SE LTS releases, effectively meaning a three-year release cycle for the Jakarta EE Platform and Profiles. Please join in on the discussions on the mailing list and the weekly platform project calls.
The JakartaOne Livestream 2021 Call-for-Paper is open! Take this opportunity and submit your talk to the third edition of this one-day virtual conference. If you are a new speaker, take a look at the previous editions for inspiration. If you have spoken at any of, or both, the previous events, make sure to complete your collection of the JakartaOne Livestream buttons.
Our next Jakarta EE Update call is coming up on Wednesday, July 14th. Join in to get the latest updates from the Jakarta EE working group. It is an informal event where you will be able to ask any questions you may have, and hopefully get them answered. Refer to the Jakarta EE Community Calendar for details.
The weekly calls in the Jakarta EE Platform project continue. Last week’s call was largely dominated by discussions around versioning schemes. I expect that this will continue in this week’s call as well.
If you arrange calls for your Jakarta specification project, please do remember to add them to the calendar, so everyone interested is able to join. Both for once-in-a-while, ad-hoc as well as regular calls.
I have previously described how to migrate manually from the javax.* to jakarta.* namespace in this migration guide. While this migration is a pretty easy task, it can be time-consuming and error-prone. But don’t despair, the community is coming to your help by providing tools that can do this for you, or at least assist you in the process. Just take a look at these:
The Tomcat Migration Tool for Jakarta EE provides easy-to-use command-line tooling for transforming Jakarta EE applications on the javax.* namespace over to jakarta.*. You can choose between two profiles depending on whether you are using the Jakarta EE APIs supported by Apache Tomcat, or the entire suite of specifications.
The Eclipse Transformer also provides transformation of Jakarta EE applications on the javax.* namespace to jakarta.*. It can operate on source files as well as class files and has an extensive set of configuration options. The Eclipse Transformer can also be used as a custom class loader, so it can perform the transformation at runtime.
In the upcoming 2021.2 version of IntelliJ IDEA, there will be built-in support for migrating from javax.* to jakarta.*. Check out Automatic migration from Java EE to Jakarta EE for a description of the functionality. If you look closely, you will notice that the sample application they are using is my Complete Duke application that I use to demo the namespace change. You can find it, and others in my Jakarta EE Duke sample projects. It is awesome that the folks at JetBrains found my demo app useful enough to use for showcasing this feature!
As I mentioned above, the Eclipse Transformer provides custom classloader capabilities so the namespace migration can be done at runtime. Many of the Jakarta EE implementations are using this technology in the Jakarta EE 9 and Jakarta EE 9.1 compatible products. I have included an example here of how you can run a Jakarta EE 8 application transformed to Jakarta EE 9.1 and packaged in a WildFly bootable JAR.
In our last call, we summarized the vote we have had running on the public mailing list regarding which version of Java SE to use the base for Jakarta EE 10. The preferred selection by the community (committers and non-committers) was the one labeled “Option 1”. This option establishes Java SE 11 as the base for Jakarta EE 10. That means that the Jakarta EE APIs will be able to take advantage of up-to Java SE 11 language features and the API JARs will be compiled to Java SE 11 byte code level.
The option also states that the TCK should be able to test runtimes that are using any Java SE level of 11 and above. This is actually the most interesting part for Jakarta EE application developers. As long as the implementation of my choice is offering to run on e.g. Java SE 17, I can use all the Java SE 17 features I want in my application. The fact that the APIs are compiled with Java SE 11 and aren’t exposing any language features above 11, does not really affect me that much.
It is really a win-win since it allows more conservative organizations to stay on Java SE 11 for as long as they wish while the ones more eager to stay up-front can move on to Java SE 17 and above.