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.
The 2021 JVM Ecosystem Report by Snyk was published this week. The focus of the report is on the most important aspects for Today’s JVM developers. The report shows that Java SE 11 is the dominant version of Java in production environments. It is good to see that the industry is moving past Java SE 8. This is also great input to the decision on what Java SE version to use as a baseline for Jakarta EE 10. The report also touches on application frameworks. Jakarta EE (and Java EE) is doing very well with a market share of 12.7% and 24.2% respectively.
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.