| [lyo-dev] FW: Java 8 or 11? |
|
CCing lyo-dev here. As expected, the decision is that staying on JDK 8 is more and more taxing and the benefit of not upgrading to JDK 11 as far as Jena is concerned is
very little. Our decision to follow suit and to drop JDK 8 in Lyo 5.x is very similar to our decision to drop Apache Wink from Lyo 4.x after it was moved to Apache Attic more than 5 years ago. JDK 11 LTS will be replaced with JDK 17 LTS this fall and JDK support
ended 2 years ago. If you are stuck on JDK 8 and planning to stay on Amazon Corretto JDK 8 till 2026, you will have to use Lyo 2.x or Lyo 4.x. -- –Andrew. From:
Andrii Berezovskyi <andriib@xxxxxx> Dear Andy, Aaron, Thank you for a prompt reply! If there are concerns, please link to the reports. There has been some scuttlebutt, indeed FUD, about RDF*. Thank you and apologies for unintentional participation in the FUD-spreading! I'd be interested in understanding the situation here - for example, do such integration projects upgrade at all? That is a very fair point, some of our users are stuck on Lyo 2.x versions because their environments require Jena 2 in some cases and we are not providing support for those old versions neither. I'd be interested in understanding the situation here - for example, do such integration projects upgrade at all? From our side – yes. I have not received any requests for our project, but you should not take it as a sign given how our users are tied to JDK 8 in one way or another. So this is really a choice point - keep to long lived legacy compatibility, which might be very long, or keep to some of up-to-date rolling policy. Titanium never supported JDK 8. It uses the java.net.http.HttpClient that is part of JDK 11. In this case, long-lived compatibility will be at odds with supporting JSON-LD 1.1 Thank you! I have slept on it and indeed it makes sense to move forward with those changes in the next major version. I have myself announced that Lyo 5.x will drop JDK 8 support. Thank you for your hard work and this amazing project! -- Cheers, Andrew On 2021-01-11 , at 19:13, Andy Seaborne <andy@xxxxxxxxxx<mailto:andy@xxxxxxxxxx>> wrote: Hi Andrii, On 11/01/2021 12:59, Andrii Berezovskyi wrote: Hello, Just noticed that the discussion went really fast. The discussion started on the dev@jena list. It isn't a done deal - no release yet. I am a maintainer for Eclipse Lyo and as an integration SDK, we ship JDK 8 library builds for wide compat (with Jena dependency). Our GH Actions build matrix succeeds on JDK 8, 11, 15, 16-ea, and 17-ea but this change will be breaking for
us. To be clear, we build our libraries under JDK 8 and use them under JDK 11+ where possible, so we do take advantage of better Docker compat and TLS improvements. This is the Jena projects CI:
https://ci-builds.apache.org/job/Jena/ (8), 11, 14, 15, 16 When targeting Java8 output, they have been fine. It has taken a bit of work to get the code to properly build under Java11 (javadoc issues - see dev@jena). 1) Could you please consider bumping the Jena version to 4.0 as this is a breaking change? Noted. 2) Is it possible to designate some 3.x version to receive security fixes (I think Jackson is the biggest offender we see in our GH/Snyk reports) for some time after 4.0 release? Jackson has been turbulent but I believe that the newer versions, with an architectural change 2.9 -> 2.10 do not have the security risks. Jackson is only used by jsonld-java - and it does not seem to use the vulnerable part anyway. We/Jena
took control of the version dependency so Jena could pick up CVE-fixes rather than need to sync with jsonld-java. Other JSON parsing in Jena is done differently, by a plain JSON parser, no ORM-like functionality.
RDF* is an extension, not a change so query and data that isn't using RDF* isn't changed. RDF* is already in a Jena (from 3.16.0). It does not interfere if it is not used (no reports have come in). The definition of RDF-star is emerging so Jena code for it will change. If there are concerns, please link to the reports. There has been some scuttlebutt, indeed FUD, about RDF*. so perhaps a version before that? Lyo 4.0 is on Jena 3.15 and Lyo 4.1.alpha is on 3.17 - for now without issues. I think JDK 8 support (non-Oracle) will generally stop around 2026 (https://aws.amazon.com/corretto/faqs/
and https://adoptopenjdk.net/support.html) and many integration projects are not eager to move (I just forwarded this thread to our mailing list and asked our users to begin testing their integration projects
with JDK 11 but we will see). I'd be interested in understanding the situation here - for example, do such integration projects upgrade at all? Any view on whether there is an appetite for JPMS modules? AdoptOpenJDK: Java8 is supported to at least May 2026 but Java11 to at least only Oct 2024. AdoptOpenJDK state that as long as upstream is doing releases they'll continue so I think we'll see a very long tail. Java is supposed to be on a rolling 3 year LTS. Java8 has been unusual. 3) How much trouble would it be to keep a JDK8 build of Jena without a new JSON-LD library? Are you switching libs or did Titanium drop JDK 8? It's possible to have two code lines but we have to also be realistic as to the resources we have available. Two active branches means more project work. (Insert "tragedy of the commons" comment here.) TItanium is one example - Eclipse Jetty 10 is now java11. So this is really a choice point - keep to long lived legacy compatibility, which might be very long, or keep to some of up-to-date rolling policy. Andy Thank you. -- Best regards, Andrew Berezovskyi On 2021-01-08 , at 23:45, Andy Seaborne <andy@xxxxxxxxxx<mailto:andy@xxxxxxxxxx><mailto:andy@xxxxxxxxxx>> wrote: The Jena build has been switched to produce Java11 bytecode. Nothing else in the codebase has been changed so this is easily reversible at the moment. Using SNAPSHOT artifacts will get you Java11 bytecode. There is currently some problems producing javadoc One problem is [1] on early Java11 releases (11.0.1, 11.0.2, but not the GA release 11.0.0). Update-to-date Java11 is now 11.0.9 and works Another is overlapping packages across modules using automatic module naming. These do not affect the running of Jena. Andy |