I think we agree on an 17/21 MR JAR, but let me close with one question (just for curiosity): If it is a challenge to migrate to 17 why can't they go to 21? What is that between 17 and 21 that produces such huge *additional* complexity that it would be *any* better to only go to 17? -Markus Von: James Perkins [mailto:jperkins@xxxxxxxxxx]
Gesendet: Mittwoch, 13. Dezember 2023 17:09
An: Markus Karg
Cc: Jakarta Rest project developer discussions
Betreff: Re: [rest-dev] Drop Minimum Java Requirement to Java 17 JAX-RS 4 will be a breaking change, so consumers need to modify their source code anyways. Hence I do not see why it should be a problem to also step up from 17 to 21 for those projects. So I'm still -1 for falling back to 17. I am +-0 for a multi-platform jar containing binaries compiled for both, 17 and 21, as a compromise. Note that the TCK MUST be compiled exactly to 21 anyways, still (https://jakartaee.github.io/platform/jakartaee11/JakartaEE11ReleasePlan), and that the same document says that downstreams MUST be compiled to a higher JDK level if needed, not vice versa.
While that document does indicate the TCK must be Java SE 21, I don't see why the platform specification should mandate what level a spec uses as long as it works with the minimum required version for the platform. "If a component Specification is planning a Major or Minor version update for Jakarta EE 11, then the recommendation would be to recompile and distribute the specification’s APIs at lowest required of Java SE 17 and Java SE 21.
Note: A component specification may be required to recompile to a higher Java SE level than it actually use depending on the specifications it depends on."
That seems to indicate an API compiling to Java SE 17 is perfectly acceptable.
I'm definitely not opposed to requiring Java 21 for compiling and using a release of 17. I think MR JAR's are great and very useful. Currently the API doesn't use anything specific to Java 21, but that doesn't mean we can't in the future.
In a lot of environments/workplaces it's not simple to just upgrade a Java version. For some I'm sure even getting to Java SE 17 will be a challenge. In the ideal world people just upgrade, but from experience I've never seen that happen. They will stick with older specs over upgrading the Java version. -Markus Von: James Perkins [mailto:jperkins@xxxxxxxxxx]
Gesendet: Mittwoch, 13. Dezember 2023 01:01
An: Markus Karg
Cc: Jakarta Rest project developer discussions
Betreff: Re: [rest-dev] Drop Minimum Java Requirement to Java 17 From what I've heard from co-workers that have been to conferences, users are not moving to Java 21 any time soon. Most are moving on Java 11 and may be moving to Java 17. I have no hard evidence on this, but I think we can attest to how slow companies are to pick up new Java versions :) I would also argue that Quarkus and MicroProfile are pretty heavily used as well and those are not Jakarta EE so to speak. Granted, they don't have to upgrade to Jakarta REST 4.0, however that is my argument about adoption. Note that currently in the API we use nothing Java 21 specific. I do not see that 21-LTS is a real showstopper for SeBootstrap adoption since there is no good reason to stick with older LTS releases (are there known incompatibilities?). Most JAX-RS applications are running in the Jakarta EE environment anyways. We should not limit ourself due to edge cases without a real need, but instead follow the SE release cycle as closely as we can, so we have full choice to use latest language features and API if we want to. Hence I am -1 for fallingback to 17. -Markus Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von James Perkins via rest-dev
Gesendet: Dienstag, 12. Dezember 2023 22:27
An: rest-dev
Cc: James Perkins
Betreff: [rest-dev] Drop Minimum Java Requirement to Java 17 Hello All, In PR 1168 [1] we updated the minimum JDK level to 21. With the exception of concurrency, the Jakarta REST spec is the only other individual spec not having a minimum requirement of Java 17. When the vote was made for Jakarta REST 4.0, the level then was Java 17. I'm not sure if upgrading should have technically required a revote or not, but just pointing that out. I realize the platform specs themselves are going to require Java 21. However, there is no requirement that any other specs need to require Java 21. IMO requiring Java 21 is going to limit adoption of the Jakarta REST spec outside of Jakarta EE 11. There are other projects, even SeBootstrap, that use the Jakarta REST spec outside of a Jakarta EE container. A big one consumer are the MicroProfile specs and implementations. Could we consider dropping the minimum back to Java 17?
--
-- |
