You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Andy Seaborne <an...@apache.org> on 2021/01/05 20:38:10 UTC
Java 8 or 11?
Currently, Jena is compiled to run on any JVM from Java8 onwards.
Java8 was released March 2014.
Java11 (Sept 2018) is LTS (long term support)
Java17 (due Sept 2021) is probably going to be LTS.
Should Jena switch to Java11 going forward?
This message is to ask:
Are there deployments that do regularly upgrade can not for some reason
move to the Java11 LTS platform?
There are the usually issues of moving to a newer Java. There seems
likely to be an emerging bimodal distribution of systems remaining with
Java8 and systems moving to Java11 and Java 17 (likely an LTS -
September 2021).
The question is how many systems would upgrade their Jena version and
are restricted to Java8 (and why!).
Java is evolving to better fit in the new tech landscape (e.g. better
container usage), more compact strings (significant for Jena), and
JDK-provided HTTP/2.
Some dependences or potential dependencies are Java11:
Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
Eclipse Jetty 10 and 11 now depend on Java11.
Andy
Re: Java 8 or 11?
Posted by Steve Vestal <st...@adventiumlabs.com>.
The javax dependency is in my code. This was just a modest warning in
case other folks use JAXB and Jena together.
On 1/6/2021 7:59 AM, Andy Seaborne wrote:
> Steve -
>
> Useful information - but I' not sure what the effect is here - I am a
> complete non-user of OSGi so I'm afraid someone will have to spell it
> out for me.
>
> The package in artifact javax.xml.bind:jaxb-api is javax.xml.bind --
> where does com.sun.xml.bind.v2 fit in?
>
> Jena OSGi does not use javax.xml.bind (I can't find it in the
> manifest.mf - am I looking in the wrong place?) so the issue is that
> other code is Java8 dependent. Is that your code or some other
> dependency?
>
> Andy
>
> On 06/01/2021 13:25, Steve Vestal wrote:
>> The issue has something to do with class loading the context, which
>> apparently is done differently in an osgi bundle. See, e.g.,
>> http://www.descher.at/descher-vu/2019/01/java-11-jaxb-and-osgi/
>>
>> On 1/6/2021 7:11 AM, Andy Seaborne wrote:
>>>
>>> On 05/01/2021 22:46, Steve Vestal wrote:
>>>> Support for JAXB was removed from Java11. For those using that and
>>>> Jena in osgi bundles (e.g., Eclipse plugins), my impression from
>>>> some initial experimenting and searching is that a bit of wizardry
>>>> is needed to add that on the side and get it working. I could not
>>>> find a clean and simple solution online. If anyone knows of one,
>>>> let me know.
>>>
>>> Steve,
>>>
>>> JABX - and others - have been moved out into self-contained maven
>>> artifacts.
>>>
>>> https://repo1.maven.org/maven2/javax/xml/jaxb-api/
>>>
>>> jena-geosparql uses jaxb-api and compiles for Java11.
>>>
>>> Is there something apache-jena-osgi needs to do?
>>>
>>> I have been using Jena with JDK11 for sometime - not OSGi - and
>>> haven't had problems or needsed to make adjustments that I recall. I
>>> don't understand OSGi enough to see why it makes a difference.
>>>
>>> Andy
>>>
>>>
>>>>
>>>> On 1/5/2021 2:38 PM, Andy Seaborne wrote:
>>>>> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>>>>>
>>>>> Java8 was released March 2014.
>>>>> Java11 (Sept 2018) is LTS (long term support)
>>>>> Java17 (due Sept 2021) is probably going to be LTS.
>>>>>
>>>>> Should Jena switch to Java11 going forward?
>>>>>
>>>>> This message is to ask:
>>>>>
>>>>> Are there deployments that do regularly upgrade can not for some
>>>>> reason move to the Java11 LTS platform?
>>>>>
>>>>>
>>>>> There are the usually issues of moving to a newer Java. There
>>>>> seems likely to be an emerging bimodal distribution of systems
>>>>> remaining with Java8 and systems moving to Java11 and Java 17
>>>>> (likely an LTS - September 2021).
>>>>>
>>>>> The question is how many systems would upgrade their Jena version
>>>>> and are restricted to Java8 (and why!).
>>>>>
>>>>> Java is evolving to better fit in the new tech landscape (e.g.
>>>>> better container usage), more compact strings (significant for
>>>>> Jena), and JDK-provided HTTP/2.
>>>>>
>>>>> Some dependences or potential dependencies are Java11:
>>>>>
>>>>> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>>>>>
>>>>> Eclipse Jetty 10 and 11 now depend on Java11.
>>>>>
>>>>> Andy
>>>>
>>
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
Steve -
Useful information - but I' not sure what the effect is here - I am a
complete non-user of OSGi so I'm afraid someone will have to spell it
out for me.
The package in artifact javax.xml.bind:jaxb-api is javax.xml.bind --
where does com.sun.xml.bind.v2 fit in?
Jena OSGi does not use javax.xml.bind (I can't find it in the
manifest.mf - am I looking in the wrong place?) so the issue is that
other code is Java8 dependent. Is that your code or some other dependency?
Andy
On 06/01/2021 13:25, Steve Vestal wrote:
> The issue has something to do with class loading the context, which
> apparently is done differently in an osgi bundle. See, e.g.,
> http://www.descher.at/descher-vu/2019/01/java-11-jaxb-and-osgi/
>
> On 1/6/2021 7:11 AM, Andy Seaborne wrote:
>>
>> On 05/01/2021 22:46, Steve Vestal wrote:
>>> Support for JAXB was removed from Java11. For those using that and
>>> Jena in osgi bundles (e.g., Eclipse plugins), my impression from some
>>> initial experimenting and searching is that a bit of wizardry is
>>> needed to add that on the side and get it working. I could not find
>>> a clean and simple solution online. If anyone knows of one, let me
>>> know.
>>
>> Steve,
>>
>> JABX - and others - have been moved out into self-contained maven
>> artifacts.
>>
>> https://repo1.maven.org/maven2/javax/xml/jaxb-api/
>>
>> jena-geosparql uses jaxb-api and compiles for Java11.
>>
>> Is there something apache-jena-osgi needs to do?
>>
>> I have been using Jena with JDK11 for sometime - not OSGi - and
>> haven't had problems or needsed to make adjustments that I recall. I
>> don't understand OSGi enough to see why it makes a difference.
>>
>> Andy
>>
>>
>>>
>>> On 1/5/2021 2:38 PM, Andy Seaborne wrote:
>>>> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>>>>
>>>> Java8 was released March 2014.
>>>> Java11 (Sept 2018) is LTS (long term support)
>>>> Java17 (due Sept 2021) is probably going to be LTS.
>>>>
>>>> Should Jena switch to Java11 going forward?
>>>>
>>>> This message is to ask:
>>>>
>>>> Are there deployments that do regularly upgrade can not for some
>>>> reason move to the Java11 LTS platform?
>>>>
>>>>
>>>> There are the usually issues of moving to a newer Java. There seems
>>>> likely to be an emerging bimodal distribution of systems remaining
>>>> with Java8 and systems moving to Java11 and Java 17 (likely an LTS -
>>>> September 2021).
>>>>
>>>> The question is how many systems would upgrade their Jena version
>>>> and are restricted to Java8 (and why!).
>>>>
>>>> Java is evolving to better fit in the new tech landscape (e.g.
>>>> better container usage), more compact strings (significant for
>>>> Jena), and JDK-provided HTTP/2.
>>>>
>>>> Some dependences or potential dependencies are Java11:
>>>>
>>>> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>>>>
>>>> Eclipse Jetty 10 and 11 now depend on Java11.
>>>>
>>>> Andy
>>>
>
Re: Java 8 or 11?
Posted by Aaron Coburn <ac...@apache.org>.
I have had no problem using Jena with OSGi on Java 11 (Apache Karaf). You
need one of the more recent releases of Karaf, but IIRC I didn't need to do
anything unusual.
Are there particular errors you are encountering with OSGi and Jena in a
Java 11 JRE? Perhaps we can take up the details in a separate thread.
-Aaron
On Wed, 6 Jan 2021 at 08:25, Steve Vestal <st...@adventiumlabs.com>
wrote:
> The issue has something to do with class loading the context, which
> apparently is done differently in an osgi bundle. See, e.g.,
> http://www.descher.at/descher-vu/2019/01/java-11-jaxb-and-osgi/
>
> On 1/6/2021 7:11 AM, Andy Seaborne wrote:
> >
> > On 05/01/2021 22:46, Steve Vestal wrote:
> >> Support for JAXB was removed from Java11. For those using that and
> >> Jena in osgi bundles (e.g., Eclipse plugins), my impression from some
> >> initial experimenting and searching is that a bit of wizardry is
> >> needed to add that on the side and get it working. I could not find
> >> a clean and simple solution online. If anyone knows of one, let me
> >> know.
> >
> > Steve,
> >
> > JABX - and others - have been moved out into self-contained maven
> > artifacts.
> >
> > https://repo1.maven.org/maven2/javax/xml/jaxb-api/
> >
> > jena-geosparql uses jaxb-api and compiles for Java11.
> >
> > Is there something apache-jena-osgi needs to do?
> >
> > I have been using Jena with JDK11 for sometime - not OSGi - and
> > haven't had problems or needsed to make adjustments that I recall. I
> > don't understand OSGi enough to see why it makes a difference.
> >
> > Andy
> >
> >
> >>
> >> On 1/5/2021 2:38 PM, Andy Seaborne wrote:
> >>> Currently, Jena is compiled to run on any JVM from Java8 onwards.
> >>>
> >>> Java8 was released March 2014.
> >>> Java11 (Sept 2018) is LTS (long term support)
> >>> Java17 (due Sept 2021) is probably going to be LTS.
> >>>
> >>> Should Jena switch to Java11 going forward?
> >>>
> >>> This message is to ask:
> >>>
> >>> Are there deployments that do regularly upgrade can not for some
> >>> reason move to the Java11 LTS platform?
> >>>
> >>>
> >>> There are the usually issues of moving to a newer Java. There seems
> >>> likely to be an emerging bimodal distribution of systems remaining
> >>> with Java8 and systems moving to Java11 and Java 17 (likely an LTS -
> >>> September 2021).
> >>>
> >>> The question is how many systems would upgrade their Jena version
> >>> and are restricted to Java8 (and why!).
> >>>
> >>> Java is evolving to better fit in the new tech landscape (e.g.
> >>> better container usage), more compact strings (significant for
> >>> Jena), and JDK-provided HTTP/2.
> >>>
> >>> Some dependences or potential dependencies are Java11:
> >>>
> >>> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
> >>>
> >>> Eclipse Jetty 10 and 11 now depend on Java11.
> >>>
> >>> Andy
> >>
>
>
Re: Java 8 or 11?
Posted by Steve Vestal <st...@adventiumlabs.com>.
The issue has something to do with class loading the context, which
apparently is done differently in an osgi bundle. See, e.g.,
http://www.descher.at/descher-vu/2019/01/java-11-jaxb-and-osgi/
On 1/6/2021 7:11 AM, Andy Seaborne wrote:
>
> On 05/01/2021 22:46, Steve Vestal wrote:
>> Support for JAXB was removed from Java11. For those using that and
>> Jena in osgi bundles (e.g., Eclipse plugins), my impression from some
>> initial experimenting and searching is that a bit of wizardry is
>> needed to add that on the side and get it working. I could not find
>> a clean and simple solution online. If anyone knows of one, let me
>> know.
>
> Steve,
>
> JABX - and others - have been moved out into self-contained maven
> artifacts.
>
> https://repo1.maven.org/maven2/javax/xml/jaxb-api/
>
> jena-geosparql uses jaxb-api and compiles for Java11.
>
> Is there something apache-jena-osgi needs to do?
>
> I have been using Jena with JDK11 for sometime - not OSGi - and
> haven't had problems or needsed to make adjustments that I recall. I
> don't understand OSGi enough to see why it makes a difference.
>
> Andy
>
>
>>
>> On 1/5/2021 2:38 PM, Andy Seaborne wrote:
>>> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>>>
>>> Java8 was released March 2014.
>>> Java11 (Sept 2018) is LTS (long term support)
>>> Java17 (due Sept 2021) is probably going to be LTS.
>>>
>>> Should Jena switch to Java11 going forward?
>>>
>>> This message is to ask:
>>>
>>> Are there deployments that do regularly upgrade can not for some
>>> reason move to the Java11 LTS platform?
>>>
>>>
>>> There are the usually issues of moving to a newer Java. There seems
>>> likely to be an emerging bimodal distribution of systems remaining
>>> with Java8 and systems moving to Java11 and Java 17 (likely an LTS -
>>> September 2021).
>>>
>>> The question is how many systems would upgrade their Jena version
>>> and are restricted to Java8 (and why!).
>>>
>>> Java is evolving to better fit in the new tech landscape (e.g.
>>> better container usage), more compact strings (significant for
>>> Jena), and JDK-provided HTTP/2.
>>>
>>> Some dependences or potential dependencies are Java11:
>>>
>>> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>>>
>>> Eclipse Jetty 10 and 11 now depend on Java11.
>>>
>>> Andy
>>
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
On 05/01/2021 22:46, Steve Vestal wrote:
> Support for JAXB was removed from Java11. For those using that and Jena
> in osgi bundles (e.g., Eclipse plugins), my impression from some initial
> experimenting and searching is that a bit of wizardry is needed to add
> that on the side and get it working. I could not find a clean and
> simple solution online. If anyone knows of one, let me know.
Steve,
JABX - and others - have been moved out into self-contained maven artifacts.
https://repo1.maven.org/maven2/javax/xml/jaxb-api/
jena-geosparql uses jaxb-api and compiles for Java11.
Is there something apache-jena-osgi needs to do?
I have been using Jena with JDK11 for sometime - not OSGi - and haven't
had problems or needsed to make adjustments that I recall. I don't
understand OSGi enough to see why it makes a difference.
Andy
>
> On 1/5/2021 2:38 PM, Andy Seaborne wrote:
>> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>>
>> Java8 was released March 2014.
>> Java11 (Sept 2018) is LTS (long term support)
>> Java17 (due Sept 2021) is probably going to be LTS.
>>
>> Should Jena switch to Java11 going forward?
>>
>> This message is to ask:
>>
>> Are there deployments that do regularly upgrade can not for some
>> reason move to the Java11 LTS platform?
>>
>>
>> There are the usually issues of moving to a newer Java. There seems
>> likely to be an emerging bimodal distribution of systems remaining
>> with Java8 and systems moving to Java11 and Java 17 (likely an LTS -
>> September 2021).
>>
>> The question is how many systems would upgrade their Jena version and
>> are restricted to Java8 (and why!).
>>
>> Java is evolving to better fit in the new tech landscape (e.g. better
>> container usage), more compact strings (significant for Jena), and
>> JDK-provided HTTP/2.
>>
>> Some dependences or potential dependencies are Java11:
>>
>> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>>
>> Eclipse Jetty 10 and 11 now depend on Java11.
>>
>> Andy
>
Re: Java 8 or 11?
Posted by Steve Vestal <st...@adventiumlabs.com>.
Support for JAXB was removed from Java11. For those using that and Jena
in osgi bundles (e.g., Eclipse plugins), my impression from some initial
experimenting and searching is that a bit of wizardry is needed to add
that on the side and get it working. I could not find a clean and
simple solution online. If anyone knows of one, let me know.
On 1/5/2021 2:38 PM, Andy Seaborne wrote:
> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>
> Java8 was released March 2014.
> Java11 (Sept 2018) is LTS (long term support)
> Java17 (due Sept 2021) is probably going to be LTS.
>
> Should Jena switch to Java11 going forward?
>
> This message is to ask:
>
> Are there deployments that do regularly upgrade can not for some
> reason move to the Java11 LTS platform?
>
>
> There are the usually issues of moving to a newer Java. There seems
> likely to be an emerging bimodal distribution of systems remaining
> with Java8 and systems moving to Java11 and Java 17 (likely an LTS -
> September 2021).
>
> The question is how many systems would upgrade their Jena version and
> are restricted to Java8 (and why!).
>
> Java is evolving to better fit in the new tech landscape (e.g. better
> container usage), more compact strings (significant for Jena), and
> JDK-provided HTTP/2.
>
> Some dependences or potential dependencies are Java11:
>
> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>
> Eclipse Jetty 10 and 11 now depend on Java11.
>
> Andy
Re: Java 8 or 11?
Posted by Dave Reynolds <da...@gmail.com>.
+1 to bumping version number, it is clearly a breaking change.
Dave
On 11/01/2021 12:59, Andrii Berezovskyi wrote:
> Hello,
>
> Just noticed that the discussion went really fast. 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.
>
> 1) Could you please consider bumping the Jena version to 4.0 as this is a breaking change?
> 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? I have seen reports that RDF* brings some problems to old users, 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).
> 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?
>
> Thank you.
>
> --
> Best regards,
> Andrew Berezovskyi
>
> On 2021-01-08 , at 23:45, Andy Seaborne <an...@apache.org>> 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
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212233
>
>
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
Hi Andrii,
Thank you for letting us know. It's good to hear from downstream
communities.
Andy
On 12/01/2021 09:21, Andrii Berezovskyi wrote:
> 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.
Aaron wrote: >>
>> 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 <an...@apache.org>> 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.
>
>> I have seen reports that RDF* brings some problems to old users,
>
> 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 <an...@apache.org>> 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
> [1] https://bugs.openjdk.java.net/browse/JDK-8212233
>
Re: Java 8 or 11?
Posted by Andrii Berezovskyi <an...@kth.se>.
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 <an...@apache.org>> 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.
> I have seen reports that RDF* brings some problems to old users,
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 <an...@apache.org>> 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
[1] https://bugs.openjdk.java.net/browse/JDK-8212233
Re: Java 8 or 11?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
It's also worth noting that from a security perspective continuing to support Java 8 is increasingly going to become a problem for end users. In my $dayjob we see a lot of concern about outdated software versions, even and especially so, as we move to a more containerised model. A lot of contracts are dictating security audits and mandating timelines for resolving any identified vulnerabilities. As I said previously on the discussion threads we already had to move all our runtime stuff to Java 11 because of this.
Yes any Java 8 bytecode should be forward compatible with Java 11, unless it utilises a JDK API that has changed, and users can obviously take Java 8 code and run them in Java 11 and newer. But as Aaron says it is increasingly going to prevent the project from introducing new functionality or limit our library choices.
At some point we have to make the choice to move forward even if it is painful for end users.
Rob
On 11/01/2021, 19:54, "Aaron Coburn" <ac...@apache.org> wrote:
>
> > Are you switching libs or did Titanium drop JDK 8?
Titanium never supported JDK 8. It uses the java.net.http.HttpClient that
is part of JDK 11.
> 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.
>
The central issue is that newer dependencies will begin supporting only
newer Java runtimes. Titanium is just one example; others will appear in
time.
In this case, long-lived compatibility will be at odds with supporting
JSON-LD 1.1
Aaron
>
> >
> > Thank you.
> >
> > --
> > Best regards,
> > Andrew Berezovskyi
> >
> > On 2021-01-08 , at 23:45, Andy Seaborne <andy@apache.org<mailto:
> andy@apache.org>> 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
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8212233
> >
> >
>
Re: Java 8 or 11?
Posted by Aaron Coburn <ac...@apache.org>.
>
> > Are you switching libs or did Titanium drop JDK 8?
Titanium never supported JDK 8. It uses the java.net.http.HttpClient that
is part of JDK 11.
> 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.
>
The central issue is that newer dependencies will begin supporting only
newer Java runtimes. Titanium is just one example; others will appear in
time.
In this case, long-lived compatibility will be at odds with supporting
JSON-LD 1.1
Aaron
>
> >
> > Thank you.
> >
> > --
> > Best regards,
> > Andrew Berezovskyi
> >
> > On 2021-01-08 , at 23:45, Andy Seaborne <andy@apache.org<mailto:
> andy@apache.org>> 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
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8212233
> >
> >
>
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
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.
> I have seen reports that RDF* brings some problems to old users,
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 <an...@apache.org>> 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
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8212233
>
>
Re: Java 8 or 11?
Posted by Andrii Berezovskyi <an...@kth.se>.
Hello,
Just noticed that the discussion went really fast. 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.
1) Could you please consider bumping the Jena version to 4.0 as this is a breaking change?
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? I have seen reports that RDF* brings some problems to old users, 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).
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?
Thank you.
--
Best regards,
Andrew Berezovskyi
On 2021-01-08 , at 23:45, Andy Seaborne <an...@apache.org>> 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
[1] https://bugs.openjdk.java.net/browse/JDK-8212233
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
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
[1] https://bugs.openjdk.java.net/browse/JDK-8212233
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
On 06/01/2021 08:40, Dave Reynolds wrote:
> tl;dr It'd be inconvenient but we could cope.
>
> As you say, there is likely to remain a bimodal distribution.
>
> We currently remain with the java 8 runtime (increasingly using AWS
> Corretto). Mostly this is due to the time cost of qualifying and
> updating an increasingly large number of different running systems. I
> know of no technical barriers to moving to java11.
Interesting - and AWS Correto Java11 has only a few back ported fixes
from JDK12 (actually all of one kind related to enabling compilation on
Amazon Linux 2)
>
> We do have at least one customer who, last we checked, was restricted
> (organizationally rather than technically) to java8. To be fair, the
> tool they use is not on the latest jena version anyway so we could move
> to different JVM versions for that v.s. other components, but targetting
> one platform is operationally easier hence sticking to java8 as the
> default.
>
> Dave
>
> On 05/01/2021 20:38, Andy Seaborne wrote:
>> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>>
>> Java8 was released March 2014.
>> Java11 (Sept 2018) is LTS (long term support)
>> Java17 (due Sept 2021) is probably going to be LTS.
>>
>> Should Jena switch to Java11 going forward?
>>
>> This message is to ask:
>>
>> Are there deployments that do regularly upgrade can not for some
>> reason move to the Java11 LTS platform?
>>
>>
>> There are the usually issues of moving to a newer Java. There seems
>> likely to be an emerging bimodal distribution of systems remaining
>> with Java8 and systems moving to Java11 and Java 17 (likely an LTS -
>> September 2021).
>>
>> The question is how many systems would upgrade their Jena version and
>> are restricted to Java8 (and why!).
>>
>> Java is evolving to better fit in the new tech landscape (e.g. better
>> container usage), more compact strings (significant for Jena), and
>> JDK-provided HTTP/2.
>>
>> Some dependences or potential dependencies are Java11:
>>
>> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>>
>> Eclipse Jetty 10 and 11 now depend on Java11.
>>
>> Andy
Re: Java 8 or 11?
Posted by Dave Reynolds <da...@gmail.com>.
tl;dr It'd be inconvenient but we could cope.
As you say, there is likely to remain a bimodal distribution.
We currently remain with the java 8 runtime (increasingly using AWS
Corretto). Mostly this is due to the time cost of qualifying and
updating an increasingly large number of different running systems. I
know of no technical barriers to moving to java11.
We do have at least one customer who, last we checked, was restricted
(organizationally rather than technically) to java8. To be fair, the
tool they use is not on the latest jena version anyway so we could move
to different JVM versions for that v.s. other components, but targetting
one platform is operationally easier hence sticking to java8 as the default.
Dave
On 05/01/2021 20:38, Andy Seaborne wrote:
> Currently, Jena is compiled to run on any JVM from Java8 onwards.
>
> Java8 was released March 2014.
> Java11 (Sept 2018) is LTS (long term support)
> Java17 (due Sept 2021) is probably going to be LTS.
>
> Should Jena switch to Java11 going forward?
>
> This message is to ask:
>
> Are there deployments that do regularly upgrade can not for some reason
> move to the Java11 LTS platform?
>
>
> There are the usually issues of moving to a newer Java. There seems
> likely to be an emerging bimodal distribution of systems remaining with
> Java8 and systems moving to Java11 and Java 17 (likely an LTS -
> September 2021).
>
> The question is how many systems would upgrade their Jena version and
> are restricted to Java8 (and why!).
>
> Java is evolving to better fit in the new tech landscape (e.g. better
> container usage), more compact strings (significant for Jena), and
> JDK-provided HTTP/2.
>
> Some dependences or potential dependencies are Java11:
>
> Titanium - for JSON-LD 1.1 (JENA-1948 - titanium-json-ld )
>
> Eclipse Jetty 10 and 11 now depend on Java11.
>
> Andy