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.