JakartaOne Livestream is a one-day virtual conference that focuses on Cloud Native Java, MicroProfile, and Jakarta EE. The Call for Paper is open from July 15 to September 15. But don’t wait, submit your abstract NOW for a chance to speak at an event attended by more than 1000 participants. Check out the previous events for inspiration:
– JakartaOne Livestream 2019
– JakartaOne Livestream 2020
Welcome to the eightieth issue of Hashtag Jakarta EE!
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.
Check out the Jakarta EE Specifications Calendar for meeting details. There are several other regular calls listed here as well. The Jakarta CDI project meets weekly. The same goes for Jakarta Config, while Jakarta MVC has monthly calls.
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.
The number of compatible products for Jakarta EE 9.1 continues to rise. The Jakarta EE 9.1 Platform Compatible Products are Eclipse GlassFish, ManageFish Server, Open Liberty, Payara Server Community, and WildFly.
The Jakarta EE 9.1 Web Profile Compatible Products are Apache TomEE, Eclipse GlassFish, Open liberty, and WildFly.
If you are doing some interesting work that involves Jakarta EE technologies, please do reach out to me. I will be happy to add it to an upcoming issue of Hashtag Jakarta EE.
Welcome to the seventy-ninth issue of Hashtag Jakarta EE!
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.
Welcome to the seventy-eighth issue of Hashtag Jakarta EE!
Summer is here (at least for those of us located in the Northern hemisphere…) and things are slowing down a little everywhere. But, the Jakarta EE Platform project continues to check items off the list preparing for Jakarta EE 10.
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.
Do check out the meeting minutes from our weekly platform calls, and don’t forget to subscribe to the platform project mailing list if you want to participate in these discussions.
Welcome to the seventy-seventh issue of Hashtag Jakarta EE!
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.
The article Java EE and Jakarta EE: What IT leaders should know in The Enterprisers Project highlights how Jakarta EE helps bridge old and new technologies in hybrid cloud environments.
On Tuesday, June 24, I will be presenting Beyond Jakarta EE 9.1 at jOnConf 2021. At the end of the day, I will be participating in a panel with the topic Software Architectures: Enterprise Java.
Eclipse GlassFish 6.2.0 was released this week! This version includes Eclipse Krazo, which means that Jakarta MVC is supported out of the box. A huge milestone for Jakarta MVC!
As I mentioned in Hashtag Jakarta EE #76, the Jakarta EE Platform project is in the process of determining the Java SE requirements for Jakarta EE 10. In this post, I try to shed some light on the implications of the various options currently up for a vote. What do these options actually mean for:
a) the Jakarta EE API developers
b) the vendors/projects implementing Jakarta EE specifications, and
c) the application developers.
I have discussed the options and the implications for these three groups below.
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.
a) API developers are restricted to the language features in Java SE 11. This means that features such as Records can not be used in the APIs. The API JARs must be compiled to Java SE 11 class level.
b) Implementors can implement their compatible implementations using any language features from any Java SE version. They may choose to certify using any version from 11 and higher. For example, a vendor may choose to support only Java SE 17 and higher if they wish. Or they may choose to support any Java SE version from 11 and higher.
c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. However, some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs. The upper limit of the Java SE version will depend on what version their selected implementation (runtime) supports.
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.
a) API developers are restricted to the language features in Java SE 11. This means that features such as Records can not be used in the APIs. The API JARs must be compiled to Java SE 17 class level.
b) Implementors can implement their compatible implementations using any language features from any Java SE version. They have to certify using Java SE 17 or higher.
c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. Some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs.
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.
a) API developers can use any language features from any Java SE version. This means that features such as Records can be used in the APIs. The API JARs must be compiled to Java SE 17 class level.
b) Implementors can implement their compatible implementations using any language features from any Java SE version. They have to certify using Java SE 17 or higher.
c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like.
As an application developer, I would always want to use the highest version of Java SE possible, so option 3 would be my obvious choice. However, should I think as a vendor with an existing customer base, I would probably prefer option 1. This option offers full flexibility. I could please my more slow-moving customers by certifying on 11. In addition to that, I could also certify on 17 and thereby please the more impatient developers. It would also enable me to offer an upgrade path for the existing customers from 11 to 17, ensuring them that the future is bright for them as well. Option 2 doesn’t make sense to me at all. Why should the API developers be restricted to 11 language features, but required to compile to 17? And everyone else are required to use 17?
When I think about it, there aren’t that many language features between Java SE 11 and 17 that would make life that much easier for the API developers, except maybe Records that would make sense to build some support around in some of the APIs. But I don’t think that justifies the cost of leaving so many users of the technology behind as many of them are still on Java SE 8. Java SE 17 could be the baseline for Jakarta EE 11, which would allow the API developers time to let the best idioms for the newer language features be established before adding them to the specifications.
So, if you’ve read this far, you’ve probably also guessed that my favorite is Option 1.
Welcome to the seventy-sixth issue of Hashtag Jakarta EE!
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.
Do check out the Dismiss the Myths: Get to know Jakarta EE (Java EE) webinar series from Payara to get some common myths dismissed. Among other things, you will experience that Java is highly relevant, and keeps up-to-date with the changes in the IT world. And that there is a bright future for Jakarta EE!
The Call for Proposals for EclipseCon 2021 ends on Tuesday, June 15, so there is still time for you to submit your Jakarta EE talk to have a chance of being a speaker!
Welcome to the seventy-fifth issue of Hashtag Jakarta EE!
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!
Welcome to the seventy-fourth issue of Hashtag Jakarta EE!
Jakarta EE 9.1 is RELEASED! Here’s what you should do now:
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>9.1.0</version>
</dependency>Follow this migration guide for the namespace migration.
Download the Jakarta EE 9.1 Compatible Product of your choice.
Tomorrow is the last day to take the 2021 Jakarta EE Developer Survey! Please take a couple of minutes to help us shape the future direction of Jakarta EE. Now that we have released Jakarta EE 9.1, the focus is on the next release. The work has already started with the establishment of the new Jakarta EE Core Profile and discussions around the release- and versioning strategy going forward. Follow the discussions in the Jakarta EE Platform Weekly call. The survey will provide valuable input to this work.
The early bird deadline for EclipseCon 2021 is coming up! Make sure you submit your talk before June 1, 2021, for a chance to be one of the first five talks selected for the conference.
Timeline:
June 1: Early-Bird Submission Deadline
June 15: Final Submission Deadline
July 1: Notification Sent
Navigate to EclipseCon 2021 Call for Proposals and submit your Jakarta EE talk today!
Join us in celebrating a new release of Jakarta EE!
The Jakarta EE Working Group Releases Jakarta EE 9.1 as Industry Continues to Embrace Open Source Enterprise Java! Jakarta EE 9.1 adds support for Java SE 11 runtimes to the foundational Jakarta EE 9 release. This gives developers more flexibility when migrating from previous Jakarta EE releases.
In order to upgrade to the new version, simply change the dependency version in your pom.xml to 9.1.0. If you are upgrading from a version prior to Jakarta EE 9, follow the migration steps for the namespace change from javax.* to jakarta.*.
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>9.1.0</version>
</dependency><dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-web-api</artifactId>
<version>9.1.0</version>
</dependency>