|
Jad,
Jakarta move has to be done at some point. However, out hands are not tied as with the JDK baseline. For example, Jetty 10, the last version to support Java EE, was released in 2020. Jetty team maintained Jetty 9 for ca. 10 years and is not planning to
drop Jetty 10 soon. Thus, we can decide when it’s best for the Lyo community to make the move.
https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga already made the move (and so did Quarkus https://quarkus.io/blog/quarkus-3-upgrade/ ).
However, it’s important to note that Spring has an LTS release for Spring 5 (until the end of 2024). Jersey 3.1 http://blog.supol.cz/?p=278 is
also released with Jakarta 10 support (Jakarta 9 is simply JavaEE 8 renamed, which is not very exciting for the users), though it’s unclear for how long 2.x will be maintained. As
the community knows, we don’t have the bandwidth for maintaining multiple Lyo versions without a commercial demand (this would most likely entail forking Jena to backport their CVE fixes).
I would like to hear some feedback from the community on this. But for now, I’m inclined to move to JDK 17 as the baseline in Lyo 6 and from Java EE 8 / JAX-RS 2.1 to Jakarta WS RS 4.0 / Jakarta EE 10 in Lyo 7 (aka Lyo 6/7 split move).
Another option is to go more aggressive and do both moves for Lyo 6 (aka 2-in-1 move). A big downside is that it will make us unable to make security fixes to the previous major version if needed. This is because Jena refuses to support multiple versions
just like Lyo. A CVE discovered in Jena 4.x in the future would mean a necessary switch to Jena 5. With Lyo 6/7, we’d be able to make a bugfix release for Lyo 6, simply bumping the Jena 5 version. With a 2-in-1 move in Lyo 6, all users will be forced to migrate
to Jakarta when a Jena CVE is potentially discovered.
Jakarta move would require all javax. package imports to be replaced with jakarta. as well as a large update to the POM files. But there are many cool features in Jakarta 10, Jersey 3, and Spring
6. I expect otherwise minimal code changes. Lyo Designer could help a lot with the migration via an updated Jakarta EE template.
We want to ultimately hear from users. Jad/Lynxwork is one such user, so I take it as a first feedback in favour of a 2-in-1 move instead of a Lyo 6/7 split migration.
–Andrew
22 juli 2023 kl. 10:05 skrev Jad El-khoury <jad.elkhoury@xxxxxxxxxxxx>:
Should we not migrate to use Jakarta.* anyway?
From: lyo-dev <lyo-dev-bounces@xxxxxxxxxxx>
On Behalf Of Andrii Berezovskyi via lyo-dev
Sent: Thursday, 20 July 2023 19:23
To: lyo-dev@xxxxxxxxxxx
Cc: Andrii Berezovskyi <andriib@xxxxxx>
Subject: [lyo-dev] Fwd: Required Java version
FYI and a reminder that Lyo will have to follow suit (except for the jakarta.* change, which will not affect us).
Subject: Required Java version
Date:
20 July 2023 at 19:19:56 CEST
A reminder that Jena will move from requiring Java11 to requiring Java17.
The project aims to support for 2 LTS versions of Java.
Java21 is scheduled for September 19 this year and is LTS.
Some time after that date that Jena will switch, with a major version bump to Jena 5.x.y
For Fuseki, Jena5 will use jakarta.* packages.
Jena is already tested for Java17 and Java21_latest_EA on a regular basis. You can switch JVMs now.
Andy
| 
