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. 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. 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? Option 2 doesn’t make sense to me at all.
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. In addition to that, I could also certify on 17 and thereby please the more impatient developers. I could please my more slow-moving customers by certifying on 11. However, should I think as a vendor with an existing customer base, I would probably prefer option 1. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like.Īs an application developer, I would always want to use the highest version of Java SE possible, so option 3 would be my obvious choice. The API JARs must be compiled to Java SE 17 class level.Ĭ) Application developers can develop their applications using any language features from any Java SE version. This means that features such as Records can be used in the APIs.
Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.Ī) API developers can use any language features from any Java SE version. Java SE 17 as source/language level and binary level for all API JARs. Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+ Some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. They have to certify using Java SE 17 or higher.Ĭ) Application developers can develop their applications using any language features from any Java SE version. The API JARs must be compiled to Java SE 17 class level.ī) Implementors can implement their compatible implementations using any language features from any Java SE version. This means that features such as Records can not be used in the APIs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.Ī) API developers are restricted to the language features in Java SE 11. Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+ The upper limit of the Java SE version will depend on what version their selected implementation (runtime) supports. However, some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs. Or they may choose to support any Java SE version from 11 and higher.Ĭ) Application developers can develop their applications using any language features from any Java SE version. For example, a vendor may choose to support only Java SE 17 and higher if they wish. They may choose to certify using any version from 11 and higher. The API JARs must be compiled to Java SE 11 class level.ī) Implementors can implement their compatible implementations using any language features from any Java SE version. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.Ī) API developers are restricted to the language features in Java SE 11. Java SE 11 as source/language level and binary level for all API JARs. Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+ I have discussed the options and the implications for these three groups below. What do these options actually mean for:ī) the vendors/projects implementing Jakarta EE specifications, and In this post, I try to shed some light on the implications of the various options currently up for a vote. 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.