Welcome to the eighty-second issue of Hashtag Jakarta EE!
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.