Grails 7.x | why recommend JDK 17 vs 21 ?

[joelBrun]

On the Documentation for the newly released 7.0.0-M3 | Installation Requirement,
you recommend using Liberica JDK 17.
but on Spring’s JDK recommendation,
they recommend BellSoft Liberica JDK version 17 or 21.

Is there a specific advantage of using the JDK 17 instead of the JDK 21 ?
also taking into account that :

• JDK 17 LTS end of support life seemd to be until September 2029
• JDK 21 LTS end of support life September 2031

https://github.com/apache/grails-doc/blob/39800234106f4489d20ab5fdca35a1b7f8817d85/7.0.0-M3/guide/gettingStarted.html#L214

[jamesfredley]

We could change it to be worded more like https://docs.spring.io/spring-boot/system-requirements.html. min 17 through 24.

Would you mind creating a PR against: https://github.com/apache/grails-core/blob/7.0.x/grails-doc/src/en/guide/gettingStarted/requirements.adoc

[jdaugherty]

One of the downsides of recommending JDK 21 is that we haven't addressed the date inconsistencies. Grails will work with it, but there may be some unexpected date formatting. See #14200

I'd rather we recommend 17 foremost until tickets like that are addressed.

[joelBrun]

Interesting. Thank @jdaugherty for that note. Are the date formatting
to the legacy locales a hard dependency for the grails-gsp ?

Seems there is a temporary workaround to activate and still be able to use
the legacy locales with JDK 21. The hard cut is on JDK 24.

Here quoting https://openjdk.org/jeps/252 about
Use of CLDR Locale Data by Default
instead of legacy profile (JRE or COMPACT) :

Future plans for legacy locale data
In a release after JDK 9, we will stop shipping legacy locale data entirely. We will gradually degrade support for legacy locale data:

JDK 21: If JRE or COMPAT is specified in the value of the system property java.locale.providers at startup, then the Java runtime will issue a warning message about the forthcoming removal of legacy locale data.

JDK 23: We will no longer include the legacy locale data in the JDK. Specifying JRE or COMPAT via -Djava.locale.providers=... will have no effect whatsoever.

Does this make sense ?
And Is there other limits observed so far with JDK21 ?

[jdaugherty]

I don't think it's a hard dependency, but the work hasn't been done to investigate it.

Yes, there is a workaround, but the goal of choosing a default JDK is to not have people use workarounds. I suspect the date formatting issues are minor / not disruptive, but I haven't had time to investigate it - hence why I'm hesitant to recommend 21 as the default.

We welcome any help on this issue: If you have time to look into the ticket & the associated Spring documentation, it would be helpful. There are tests in grails-core that were "fixed" by selectively running on jdk versions. They need reviewed at a minimum in addition to the ticket + associated spring documentation.

Our main focus is getting 7.0 released right now, and until that's done I don't think we want to expand the scope by changing the recommended default JDK. We had several last minute requirements due to the ASF merge and it's consuming almost all of the development time to get an ASF release done. Due to the limited resource, I'd suggest we leave it at 17 for now. We do test in parallel with Linux / Mac / Windows across JDK 17, 21, & 23 now - so we know that the impacts of JDK 21 will be limited; likely just this date issue.

On the horizon, we'll have a more regular release cycle after 7. We'll effectively mirror Spring's. One of the main goals of the mono repo merge was to accelerate releases so we don't have a huge effort on updating dependencies in the future. So while Grails 7 will release after a significant development time, Grails 8 will likely come within the year. We can recommend JDK 21 at that time.

[jdaugherty]

I think this question is answered. We are making changes to better support & test JDK 21, but I think the base version will be 17 since Spring suggests it. I'm going to close this ticket.