Hashtag Jakarta EE #83

Welcome to the eighty-third issue of Hashtag Jakarta EE!

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.

Using Eclipse Krazo Jersey with Eclipse Jersey

<dependency>
  <groupId>jakarta.mvc</groupId>
  <artifactId>jakarta.mvc-api</artifactId>
  <version>2.0.0</version>
</dependency>

<dependency>
  <groupId>org.eclipse.krazo</groupId>
  <artifactId>krazo-core</artifactId>
  <version>2.0.1</version>
</dependency>
<dependency>
  <groupId>org.eclipse.krazo</groupId>
  <artifactId>krazo-jersey</artifactId>
  <version>2.0.1</version>
</dependency>

Using Eclipse Krazo with RESTEasy

<dependency>
  <groupId>jakarta.mvc</groupId>
  <artifactId>jakarta.mvc-api</artifactId>
  <version>2.0.0</version>
</dependency>

<dependency>
  <groupId>org.eclipse.krazo</groupId>
  <artifactId>krazo-core</artifactId>
  <version>2.0.1</version>
</dependency>
<dependency>
  <groupId>org.eclipse.krazo</groupId>
  <artifactId>krazo-resteasy</artifactId>
  <version>2.0.1</version>
</dependency>

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…

Hashtag Jakarta EE #82

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.

Hashtag Jakarta EE #81

Welcome to the eighty-first issue of Hashtag Jakarta EE!

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.

...
    <maven.compiler.release>11</maven.compiler.release>
...

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.

JakartaOne Livestream 2021 CFP is OPEN!

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

Hashtag Jakarta EE #80

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.

Get Listed!

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.

Hashtag Jakarta EE #79

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.

Hashtag Jakarta EE #78

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.

Hashtag Jakarta EE #77

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!

Demystifying Java SE Level for Jakarta EE

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.

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.

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.

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.

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.

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.

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.

Conclusion

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.

Hashtag Jakarta EE #76

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!