You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2021/01/01 12:13:26 UTC
Java 8 or 11?
Should we switch to Java11?
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.
(the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
package root name "javax..." whereas Jetty11 uses package route
"jakarta...")
Proposal:
1/ Ask on users@ -- what we need is "new information" such as "I am
blocked from updating Java because ...", not "I haven't got round to it".
2/ Switch to Java11 for the next release but not make so many changes
that we can't easily go back to Java8.
Andy
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
Seems reasonable. Would someone like to help set this up?
Which aspect - the PR validation (travis) and/or the development build
(Jenkins).
The project development on ASF Jenkins (and is operated by CloudBees) at
the moment) is our main CI with builds for Java11, building for Java11
using 14, 15, 16 JDK and a Windows build.
https://ci-builds.apache.org/job/Jena/
The Travis file went in to help other people and with ASF infra changes
we started getting PR checking for no effort on our part.
If you read the builds@ list, you'll see that GH actions are not without
their issues :-)
On 08/01/2021 19:57, Aaron Coburn wrote:
> On Fri, 8 Jan 2021 at 14:33, Martynas Jusevičius <ma...@atomgraph.com>
> wrote:
>
>> Suggestion: migrate builds to GitHub actions. I just did that for our
>> test suites.
>>
>> https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works
ASF gets access to Travis (travis-ci.com) and GH actions (and, I think,
special foundation limits).
The Travis is currently overloaded making it a long time for jobs to run.
It has been quite eventful for main projects on both Trivis and GH
action recently.
But Jena's build is really very simple.
> +1
>
> (I used travis-ci for a long time, but now I use GH actions almost
> exclusively)
Most of my active personal projects are using GH actions.
Andy
>
>
>>
>>
>> On Fri, Jan 8, 2021 at 6:38 PM Andy Seaborne <an...@apache.org> wrote:
>>>
>>> Status: JENA-2022
>>>
>>> One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which
>>> hits a javadoc problem
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8212233
>>>
>>> (it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA
>>> release, or 11.0.3 or later, then 12.0.0, 12.0.1)
>>>
>>> I think this is triggered by cross links in Java source code from one
>>> module to another when the modules have Automatic-Module-Name. The fixes
>>> mentioned don't work for Jena.
>>>
>>> See also https://issues.apache.org/jira/browse/MJAVADOC-555
>>>
>>> There are no problems building with the default Java11 on my machine
>>> (11.0.9)
>>>
>>> For now I have switched off javadoc production in the .travis.yml file.
>>>
>>> It should be OK on ASF Jenkins because there, we control the JDK (and
>>> only 11.0.9 in various forms is available anyway).
>>>
>>> What the travis file does for us is that PRs automatically get a check
>>> applied of running the build with the PR at travis (it can take a while
>>> to get scheduled and run). We didn't ask INFRA for this - recent
>>> infrastructure changes mean it just happens.
>>>
>>> Andy
>>>
>>> On 01/01/2021 12:13, Andy Seaborne wrote:
>>>> Should we switch to Java11?
>>>>
>>>> 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.
>>>>
>>>> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
>>>> package root name "javax..." whereas Jetty11 uses package route
>>>> "jakarta...")
>>>>
>>>> Proposal:
>>>>
>>>> 1/ Ask on users@ -- what we need is "new information" such as "I am
>>>> blocked from updating Java because ...", not "I haven't got round to
>> it".
>>>>
>>>> 2/ Switch to Java11 for the next release but not make so many changes
>>>> that we can't easily go back to Java8.
>>>>
>>>> Andy
>>
>
Re: Java 8 or 11?
Posted by Aaron Coburn <ac...@apache.org>.
On Fri, 8 Jan 2021 at 14:33, Martynas Jusevičius <ma...@atomgraph.com>
wrote:
> Suggestion: migrate builds to GitHub actions. I just did that for our
> test suites.
>
> https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works
+1
(I used travis-ci for a long time, but now I use GH actions almost
exclusively)
>
>
> On Fri, Jan 8, 2021 at 6:38 PM Andy Seaborne <an...@apache.org> wrote:
> >
> > Status: JENA-2022
> >
> > One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which
> > hits a javadoc problem
> >
> > https://bugs.openjdk.java.net/browse/JDK-8212233
> >
> > (it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA
> > release, or 11.0.3 or later, then 12.0.0, 12.0.1)
> >
> > I think this is triggered by cross links in Java source code from one
> > module to another when the modules have Automatic-Module-Name. The fixes
> > mentioned don't work for Jena.
> >
> > See also https://issues.apache.org/jira/browse/MJAVADOC-555
> >
> > There are no problems building with the default Java11 on my machine
> > (11.0.9)
> >
> > For now I have switched off javadoc production in the .travis.yml file.
> >
> > It should be OK on ASF Jenkins because there, we control the JDK (and
> > only 11.0.9 in various forms is available anyway).
> >
> > What the travis file does for us is that PRs automatically get a check
> > applied of running the build with the PR at travis (it can take a while
> > to get scheduled and run). We didn't ask INFRA for this - recent
> > infrastructure changes mean it just happens.
> >
> > Andy
> >
> > On 01/01/2021 12:13, Andy Seaborne wrote:
> > > Should we switch to Java11?
> > >
> > > 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.
> > >
> > > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> > > package root name "javax..." whereas Jetty11 uses package route
> > > "jakarta...")
> > >
> > > Proposal:
> > >
> > > 1/ Ask on users@ -- what we need is "new information" such as "I am
> > > blocked from updating Java because ...", not "I haven't got round to
> it".
> > >
> > > 2/ Switch to Java11 for the next release but not make so many changes
> > > that we can't easily go back to Java8.
> > >
> > > Andy
>
Re: Java 8 or 11?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Suggestion: migrate builds to GitHub actions. I just did that for our
test suites.
https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works
On Fri, Jan 8, 2021 at 6:38 PM Andy Seaborne <an...@apache.org> wrote:
>
> Status: JENA-2022
>
> One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which
> hits a javadoc problem
>
> https://bugs.openjdk.java.net/browse/JDK-8212233
>
> (it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA
> release, or 11.0.3 or later, then 12.0.0, 12.0.1)
>
> I think this is triggered by cross links in Java source code from one
> module to another when the modules have Automatic-Module-Name. The fixes
> mentioned don't work for Jena.
>
> See also https://issues.apache.org/jira/browse/MJAVADOC-555
>
> There are no problems building with the default Java11 on my machine
> (11.0.9)
>
> For now I have switched off javadoc production in the .travis.yml file.
>
> It should be OK on ASF Jenkins because there, we control the JDK (and
> only 11.0.9 in various forms is available anyway).
>
> What the travis file does for us is that PRs automatically get a check
> applied of running the build with the PR at travis (it can take a while
> to get scheduled and run). We didn't ask INFRA for this - recent
> infrastructure changes mean it just happens.
>
> Andy
>
> On 01/01/2021 12:13, Andy Seaborne wrote:
> > Should we switch to Java11?
> >
> > 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.
> >
> > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> > package root name "javax..." whereas Jetty11 uses package route
> > "jakarta...")
> >
> > Proposal:
> >
> > 1/ Ask on users@ -- what we need is "new information" such as "I am
> > blocked from updating Java because ...", not "I haven't got round to it".
> >
> > 2/ Switch to Java11 for the next release but not make so many changes
> > that we can't easily go back to Java8.
> >
> > Andy
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
More javadoc problems triggered by Automatic-Module-Name.
https://ci-builds.apache.org/job/Jena/job/Jena_Development_Deploy/63/
[ERROR] Exit code: 1 - error: module org.apache.jena.dboe.trans.data
reads package jena from both org.apache.jena.text and org.apache.jena.cmds
(yes, an overlapping package that shouldn't)
I'll take a look as soon as I can.
Andy
On 08/01/2021 17:38, Andy Seaborne wrote:
> Status: JENA-2022
>
> One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which
> hits a javadoc problem
>
> https://bugs.openjdk.java.net/browse/JDK-8212233
>
> (it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA
> release, or 11.0.3 or later, then 12.0.0, 12.0.1)
>
> I think this is triggered by cross links in Java source code from one
> module to another when the modules have Automatic-Module-Name. The fixes
> mentioned don't work for Jena.
>
> See also https://issues.apache.org/jira/browse/MJAVADOC-555
>
> There are no problems building with the default Java11 on my machine
> (11.0.9)
>
> For now I have switched off javadoc production in the .travis.yml file.
>
> It should be OK on ASF Jenkins because there, we control the JDK (and
> only 11.0.9 in various forms is available anyway).
>
> What the travis file does for us is that PRs automatically get a check
> applied of running the build with the PR at travis (it can take a while
> to get scheduled and run). We didn't ask INFRA for this - recent
> infrastructure changes mean it just happens.
>
> Andy
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
Status: JENA-2022
One slight problem - on travis-ci.org, the Java11 system is 11.0.2 which
hits a javadoc problem
https://bugs.openjdk.java.net/browse/JDK-8212233
(it says Java12 but it applies to 11.0.1, and 11.0.2, not 11.0.0, the GA
release, or 11.0.3 or later, then 12.0.0, 12.0.1)
I think this is triggered by cross links in Java source code from one
module to another when the modules have Automatic-Module-Name. The fixes
mentioned don't work for Jena.
See also https://issues.apache.org/jira/browse/MJAVADOC-555
There are no problems building with the default Java11 on my machine
(11.0.9)
For now I have switched off javadoc production in the .travis.yml file.
It should be OK on ASF Jenkins because there, we control the JDK (and
only 11.0.9 in various forms is available anyway).
What the travis file does for us is that PRs automatically get a check
applied of running the build with the PR at travis (it can take a while
to get scheduled and run). We didn't ask INFRA for this - recent
infrastructure changes mean it just happens.
Andy
On 01/01/2021 12:13, Andy Seaborne wrote:
> Should we switch to Java11?
>
> 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.
>
> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> package root name "javax..." whereas Jetty11 uses package route
> "jakarta...")
>
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
> Andy
Re: Java 8 or 11?
Posted by Aaron Coburn <aa...@gmail.com>.
At this point, Java8 is no longer supported by Oracle. (OpenJDK and AWS
Corretto will both continue to support security updates), and from what
I've been seeing, much of the Java ecosystem is moving in this direction,
too.
Everything I work on uses Java 11, so I am generally +1 on moving in this
direction. (The ability to use Titanium is compelling for me)
The steps proposed sound very reasonable to me.
Aaron
On Fri, 1 Jan 2021 at 09:59, Martynas Jusevičius <ma...@atomgraph.com>
wrote:
> I recently upgraded AtomGraph components to Java 11 and took advantage
> of the -XX:MaxRAMPercentage JVM setting in a Docker setup:
> https://www.eclipse.org/openj9/docs/xxinitialrampercentage/
>
> On Fri, Jan 1, 2021 at 1:13 PM Andy Seaborne <an...@apache.org> wrote:
> >
> > Should we switch to Java11?
> >
> > 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.
> >
> > (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> > package root name "javax..." whereas Jetty11 uses package route
> > "jakarta...")
> >
> > Proposal:
> >
> > 1/ Ask on users@ -- what we need is "new information" such as "I am
> > blocked from updating Java because ...", not "I haven't got round to it".
> >
> > 2/ Switch to Java11 for the next release but not make so many changes
> > that we can't easily go back to Java8.
> >
> > Andy
>
Re: Java 8 or 11?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
I recently upgraded AtomGraph components to Java 11 and took advantage
of the -XX:MaxRAMPercentage JVM setting in a Docker setup:
https://www.eclipse.org/openj9/docs/xxinitialrampercentage/
On Fri, Jan 1, 2021 at 1:13 PM Andy Seaborne <an...@apache.org> wrote:
>
> Should we switch to Java11?
>
> 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.
>
> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> package root name "javax..." whereas Jetty11 uses package route
> "jakarta...")
>
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
> Andy
Re: Java 8 or 11?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
+1
Yep, we've been moved over to Java 11 for a while now
Rob
On 03/01/2021, 10:39, "Dr. Chavdar Ivanov" <ch...@outlook.hu> wrote:
+1
-----Original Message-----
From: ajs6f@apache.org <aj...@apache.org>
Sent: Saturday, 2 January, 2021 17:57
To: dev@jena.apache.org; Bruno P. Kinoshita <ki...@apache.org>
Subject: Re: Java 8 or 11?
+1. This will only get more pressing with time.
Adam
On Fri, Jan 1, 2021, 8:36 PM Bruno P. Kinoshita <ki...@apache.org> wrote:
> I'm +1 for Java 11, and to go along with your plan. First message to
> users with our intention, and asking for any known issues from their side.
>
> Bruno
>
> On Saturday, 2 January 2021, 1:13:39 am NZDT, Andy Seaborne <
> andy@apache.org> wrote:
>
> Should we switch to Java11?
>
> 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.
>
> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses
> the package root name "javax..." whereas Jetty11 uses package route
> "jakarta...")
>
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
> Andy
>
RE: Java 8 or 11?
Posted by "Dr. Chavdar Ivanov" <ch...@outlook.hu>.
+1
-----Original Message-----
From: ajs6f@apache.org <aj...@apache.org>
Sent: Saturday, 2 January, 2021 17:57
To: dev@jena.apache.org; Bruno P. Kinoshita <ki...@apache.org>
Subject: Re: Java 8 or 11?
+1. This will only get more pressing with time.
Adam
On Fri, Jan 1, 2021, 8:36 PM Bruno P. Kinoshita <ki...@apache.org> wrote:
> I'm +1 for Java 11, and to go along with your plan. First message to
> users with our intention, and asking for any known issues from their side.
>
> Bruno
>
> On Saturday, 2 January 2021, 1:13:39 am NZDT, Andy Seaborne <
> andy@apache.org> wrote:
>
> Should we switch to Java11?
>
> 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.
>
> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses
> the package root name "javax..." whereas Jetty11 uses package route
> "jakarta...")
>
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
> Andy
>
Re: Java 8 or 11?
Posted by aj...@apache.org.
+1. This will only get more pressing with time.
Adam
On Fri, Jan 1, 2021, 8:36 PM Bruno P. Kinoshita <ki...@apache.org> wrote:
> I'm +1 for Java 11, and to go along with your plan. First message to
> users with our intention, and asking for any known issues from their side.
>
> Bruno
>
> On Saturday, 2 January 2021, 1:13:39 am NZDT, Andy Seaborne <
> andy@apache.org> wrote:
>
> Should we switch to Java11?
>
> 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.
>
> (the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
> package root name "javax..." whereas Jetty11 uses package route
> "jakarta...")
>
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
> Andy
>
Re: Java 8 or 11?
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
I'm +1 for Java 11, and to go along with your plan. First message to users with our intention, and asking for any known issues from their side.
Bruno
On Saturday, 2 January 2021, 1:13:39 am NZDT, Andy Seaborne <an...@apache.org> wrote:
Should we switch to Java11?
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.
(the difference between Jetty 10 and Jetty 11 is that Jetty 10 uses the
package root name "javax..." whereas Jetty11 uses package route
"jakarta...")
Proposal:
1/ Ask on users@ -- what we need is "new information" such as "I am
blocked from updating Java because ...", not "I haven't got round to it".
2/ Switch to Java11 for the next release but not make so many changes
that we can't easily go back to Java8.
Andy
jena-iri [was: Java 8 or 11?]
Posted by Andy Seaborne <an...@apache.org>.
>>> 2/ Retire modules or remove code we do not want to migrate to Jena4,
>>> especially as we can still include it again later if there is
>>> unanticipated user demand. Again, a major version jump is a time to be
>>> bold(er); all code has cost.
>>>
>>> jena-text-es is a candidate from my point of view. No one is maintaining
>>> it and it is complicated to setup and support.
One I have my eye on long-term is jena-iri.
Good news is that is very stable and the last change was to update the
handling of URN fragments which was a small point change.
jena-iri is hard to build from scratch (there are steps outside the
maven build to get the generated code to happen).
Current IRI parsing is slow - using several subparsers. RIOT has a cache
in front of it to address the speed issue.
Jena uses only a small part of it. It requires checking of strings,
resolve relative IRIs, and calculate relative IRIs for output.
It is better to have a IRI implementation that complies exactly with the
RFC3986 standard. The JDK one does not.
This
https://github.com/afs/iri4ld
is simple (one class for the handing of IRIs).
It provides parsing efficiently and faster. It is zero-copy to check a
string is a valid IRI. The parser is written in Java, not generated. It
is commented and all in one place so maintenance is much easier.
It is only RFC3986 URI/IRIs, not variants like RDF 1.0's "RDF URI
reference" (which is not in RDF 1.1).
It is not as strong on messages for errors and warning for the "not
recommended" uses in IRIs. (There is a framework for adding them.)
Andy
Re: SDB [was: Java 8 or 11?]
Posted by "A. Soroka" <so...@gmail.com>.
+1!
Adam
On Wed, Jan 27, 2021, 4:31 PM Bruno P. Kinoshita <ki...@apache.org> wrote:
> Makes sense to me, I'm only using TDB (I think I only ever used SDB
> following an old tutorial for some inference or another tool that had used
> SDB, long time ago). +1
>
> On Thursday, 28 January 2021, 10:08:39 am NZDT, Andy Seaborne <
> andy@apache.org> wrote:
>
> I checked with with VIVO and they are migtrating to TDB as the primary
> store.
>
> https://jira.lyrasis.org/browse/VIVO-1741
>
> If we retire SDB, they will do the same on their end.
>
> And anyway we can put it back again easily enough.
>
> The IRI changes (which include API changes) cause a few changes in SDB
> because SDB is old and uses what are nowadays really non-public APIs.
> It's easy to fix up, so if we archive just before the next release it'll
> practical that anyone missing it can a version build immediately, not
> wait for a release cycle.
>
> Andy
>
> On 25/01/2021 11:15, Andy Seaborne wrote:
> > It is semi-retired saying "not suitable for new work".
> >
> > There's an open source project using it (vivoweb); they plan to move off
> > it. Someone showed up awhile ago (about a year ago). So while they are
> > migrating (and it isn't instant for them and their downstream), I'm
> > happy to personally keep it alive for now for small things. I had a call
> > with them back then and they know the situation.
> >
> > If the unlikely occurs and some major change is needed, it will get
> > dropped from the build. I like this division of modules into "essential"
> > and "droppable".
> >
> > Given SDB is not tightly integrated in with other parts of Jena (due to
> > age), the mostly likely threat to it is a security risk. I would not
> > want a release have a CVE against it just because of SDB.
> >
> > Then definitely; less is more.
> >
> > Andy
> >
> > On 23/01/2021 01:47, ajs6f@apache.org wrote:
> >> Is SDB perhaps another candidate for retirement?
> >>
> >> Adam
> >>
> >> On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne <an...@apache.org> wrote:
> >>
> >>>
> >>> On 01/01/2021 12:13, Andy Seaborne wrote:
> >>>> Should we switch to Java11?
> >>>> Proposal:
> >>>>
> >>>> 1/ Ask on users@ -- what we need is "new information" such as "I am
> >>>> blocked from updating Java because ...", not "I haven't got round to
> >>>> it".
> >>>>
> >>>> 2/ Switch to Java11 for the next release but not make so many changes
> >>>> that we can't easily go back to Java8.
> >>>>
> >>>> Andy
> >>>
> >>> The discussion on users@
> >>>
> >>>
> >>>
> https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
> >>>
> >>>
> >>> Points:
> >>> * bump to Jena4.
> >>> * request to keep a parallel 3.x branch (nice if resourced only if
> >>> resourced)
> >>>
> >>> If Jena4, then are there any things we can do which won't significant
> >>> impact the timescale - we can take longer of course but I think any
> >>> major work item that would need several additional months, and all the
> >>> risk of that slipping :-), really must be important.
> >>>
> >>> 1/ Mass removal of deprecated - a lot has been deprecated for many
> >>> versions so removing it a 4.x seems reasonable. I hope people have been
> >>> taking note but code can always return if necessary.
> >>>
> >>> 2/ Retire modules or remove code we do not want to migrate to Jena4,
> >>> especially as we can still include it again later if there is
> >>> unanticipated user demand. Again, a major version jump is a time to be
> >>> bold(er); all code has cost.
> >>>
> >>> jena-text-es is a candidate from my point of view. No one is
> maintaining
> >>> it and it is complicated to setup and support.
> >>>
> >>> Andy
> >>>
> >>
>
Re: SDB [was: Java 8 or 11?]
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
Makes sense to me, I'm only using TDB (I think I only ever used SDB following an old tutorial for some inference or another tool that had used SDB, long time ago). +1
On Thursday, 28 January 2021, 10:08:39 am NZDT, Andy Seaborne <an...@apache.org> wrote:
I checked with with VIVO and they are migtrating to TDB as the primary
store.
https://jira.lyrasis.org/browse/VIVO-1741
If we retire SDB, they will do the same on their end.
And anyway we can put it back again easily enough.
The IRI changes (which include API changes) cause a few changes in SDB
because SDB is old and uses what are nowadays really non-public APIs.
It's easy to fix up, so if we archive just before the next release it'll
practical that anyone missing it can a version build immediately, not
wait for a release cycle.
Andy
On 25/01/2021 11:15, Andy Seaborne wrote:
> It is semi-retired saying "not suitable for new work".
>
> There's an open source project using it (vivoweb); they plan to move off
> it. Someone showed up awhile ago (about a year ago). So while they are
> migrating (and it isn't instant for them and their downstream), I'm
> happy to personally keep it alive for now for small things. I had a call
> with them back then and they know the situation.
>
> If the unlikely occurs and some major change is needed, it will get
> dropped from the build. I like this division of modules into "essential"
> and "droppable".
>
> Given SDB is not tightly integrated in with other parts of Jena (due to
> age), the mostly likely threat to it is a security risk. I would not
> want a release have a CVE against it just because of SDB.
>
> Then definitely; less is more.
>
> Andy
>
> On 23/01/2021 01:47, ajs6f@apache.org wrote:
>> Is SDB perhaps another candidate for retirement?
>>
>> Adam
>>
>> On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne <an...@apache.org> wrote:
>>
>>>
>>> On 01/01/2021 12:13, Andy Seaborne wrote:
>>>> Should we switch to Java11?
>>>> Proposal:
>>>>
>>>> 1/ Ask on users@ -- what we need is "new information" such as "I am
>>>> blocked from updating Java because ...", not "I haven't got round to
>>>> it".
>>>>
>>>> 2/ Switch to Java11 for the next release but not make so many changes
>>>> that we can't easily go back to Java8.
>>>>
>>>> Andy
>>>
>>> The discussion on users@
>>>
>>>
>>> https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
>>>
>>>
>>> Points:
>>> * bump to Jena4.
>>> * request to keep a parallel 3.x branch (nice if resourced only if
>>> resourced)
>>>
>>> If Jena4, then are there any things we can do which won't significant
>>> impact the timescale - we can take longer of course but I think any
>>> major work item that would need several additional months, and all the
>>> risk of that slipping :-), really must be important.
>>>
>>> 1/ Mass removal of deprecated - a lot has been deprecated for many
>>> versions so removing it a 4.x seems reasonable. I hope people have been
>>> taking note but code can always return if necessary.
>>>
>>> 2/ Retire modules or remove code we do not want to migrate to Jena4,
>>> especially as we can still include it again later if there is
>>> unanticipated user demand. Again, a major version jump is a time to be
>>> bold(er); all code has cost.
>>>
>>> jena-text-es is a candidate from my point of view. No one is maintaining
>>> it and it is complicated to setup and support.
>>>
>>> Andy
>>>
>>
SDB [was: Java 8 or 11?]
Posted by Andy Seaborne <an...@apache.org>.
I checked with with VIVO and they are migtrating to TDB as the primary
store.
https://jira.lyrasis.org/browse/VIVO-1741
If we retire SDB, they will do the same on their end.
And anyway we can put it back again easily enough.
The IRI changes (which include API changes) cause a few changes in SDB
because SDB is old and uses what are nowadays really non-public APIs.
It's easy to fix up, so if we archive just before the next release it'll
practical that anyone missing it can a version build immediately, not
wait for a release cycle.
Andy
On 25/01/2021 11:15, Andy Seaborne wrote:
> It is semi-retired saying "not suitable for new work".
>
> There's an open source project using it (vivoweb); they plan to move off
> it. Someone showed up awhile ago (about a year ago). So while they are
> migrating (and it isn't instant for them and their downstream), I'm
> happy to personally keep it alive for now for small things. I had a call
> with them back then and they know the situation.
>
> If the unlikely occurs and some major change is needed, it will get
> dropped from the build. I like this division of modules into "essential"
> and "droppable".
>
> Given SDB is not tightly integrated in with other parts of Jena (due to
> age), the mostly likely threat to it is a security risk. I would not
> want a release have a CVE against it just because of SDB.
>
> Then definitely; less is more.
>
> Andy
>
> On 23/01/2021 01:47, ajs6f@apache.org wrote:
>> Is SDB perhaps another candidate for retirement?
>>
>> Adam
>>
>> On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne <an...@apache.org> wrote:
>>
>>>
>>> On 01/01/2021 12:13, Andy Seaborne wrote:
>>>> Should we switch to Java11?
>>>> Proposal:
>>>>
>>>> 1/ Ask on users@ -- what we need is "new information" such as "I am
>>>> blocked from updating Java because ...", not "I haven't got round to
>>>> it".
>>>>
>>>> 2/ Switch to Java11 for the next release but not make so many changes
>>>> that we can't easily go back to Java8.
>>>>
>>>> Andy
>>>
>>> The discussion on users@
>>>
>>>
>>> https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
>>>
>>>
>>> Points:
>>> * bump to Jena4.
>>> * request to keep a parallel 3.x branch (nice if resourced only if
>>> resourced)
>>>
>>> If Jena4, then are there any things we can do which won't significant
>>> impact the timescale - we can take longer of course but I think any
>>> major work item that would need several additional months, and all the
>>> risk of that slipping :-), really must be important.
>>>
>>> 1/ Mass removal of deprecated - a lot has been deprecated for many
>>> versions so removing it a 4.x seems reasonable. I hope people have been
>>> taking note but code can always return if necessary.
>>>
>>> 2/ Retire modules or remove code we do not want to migrate to Jena4,
>>> especially as we can still include it again later if there is
>>> unanticipated user demand. Again, a major version jump is a time to be
>>> bold(er); all code has cost.
>>>
>>> jena-text-es is a candidate from my point of view. No one is maintaining
>>> it and it is complicated to setup and support.
>>>
>>> Andy
>>>
>>
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
It is semi-retired saying "not suitable for new work".
There's an open source project using it (vivoweb); they plan to move off
it. Someone showed up awhile ago (about a year ago). So while they are
migrating (and it isn't instant for them and their downstream), I'm
happy to personally keep it alive for now for small things. I had a call
with them back then and they know the situation.
If the unlikely occurs and some major change is needed, it will get
dropped from the build. I like this division of modules into "essential"
and "droppable".
Given SDB is not tightly integrated in with other parts of Jena (due to
age), the mostly likely threat to it is a security risk. I would not
want a release have a CVE against it just because of SDB.
Then definitely; less is more.
Andy
On 23/01/2021 01:47, ajs6f@apache.org wrote:
> Is SDB perhaps another candidate for retirement?
>
> Adam
>
> On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne <an...@apache.org> wrote:
>
>>
>> On 01/01/2021 12:13, Andy Seaborne wrote:
>>> Should we switch to Java11?
>>> Proposal:
>>>
>>> 1/ Ask on users@ -- what we need is "new information" such as "I am
>>> blocked from updating Java because ...", not "I haven't got round to it".
>>>
>>> 2/ Switch to Java11 for the next release but not make so many changes
>>> that we can't easily go back to Java8.
>>>
>>> Andy
>>
>> The discussion on users@
>>
>>
>> https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
>>
>> Points:
>> * bump to Jena4.
>> * request to keep a parallel 3.x branch (nice if resourced only if
>> resourced)
>>
>> If Jena4, then are there any things we can do which won't significant
>> impact the timescale - we can take longer of course but I think any
>> major work item that would need several additional months, and all the
>> risk of that slipping :-), really must be important.
>>
>> 1/ Mass removal of deprecated - a lot has been deprecated for many
>> versions so removing it a 4.x seems reasonable. I hope people have been
>> taking note but code can always return if necessary.
>>
>> 2/ Retire modules or remove code we do not want to migrate to Jena4,
>> especially as we can still include it again later if there is
>> unanticipated user demand. Again, a major version jump is a time to be
>> bold(er); all code has cost.
>>
>> jena-text-es is a candidate from my point of view. No one is maintaining
>> it and it is complicated to setup and support.
>>
>> Andy
>>
>
Re: Java 8 or 11?
Posted by aj...@apache.org.
Is SDB perhaps another candidate for retirement?
Adam
On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne <an...@apache.org> wrote:
>
> On 01/01/2021 12:13, Andy Seaborne wrote:
> > Should we switch to Java11?
> > Proposal:
> >
> > 1/ Ask on users@ -- what we need is "new information" such as "I am
> > blocked from updating Java because ...", not "I haven't got round to it".
> >
> > 2/ Switch to Java11 for the next release but not make so many changes
> > that we can't easily go back to Java8.
> >
> > Andy
>
> The discussion on users@
>
>
> https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
>
> Points:
> * bump to Jena4.
> * request to keep a parallel 3.x branch (nice if resourced only if
> resourced)
>
> If Jena4, then are there any things we can do which won't significant
> impact the timescale - we can take longer of course but I think any
> major work item that would need several additional months, and all the
> risk of that slipping :-), really must be important.
>
> 1/ Mass removal of deprecated - a lot has been deprecated for many
> versions so removing it a 4.x seems reasonable. I hope people have been
> taking note but code can always return if necessary.
>
> 2/ Retire modules or remove code we do not want to migrate to Jena4,
> especially as we can still include it again later if there is
> unanticipated user demand. Again, a major version jump is a time to be
> bold(er); all code has cost.
>
> jena-text-es is a candidate from my point of view. No one is maintaining
> it and it is complicated to setup and support.
>
> Andy
>
Re: Java 8 or 11?
Posted by Andy Seaborne <an...@apache.org>.
On 01/01/2021 12:13, Andy Seaborne wrote:
> Should we switch to Java11?
> Proposal:
>
> 1/ Ask on users@ -- what we need is "new information" such as "I am
> blocked from updating Java because ...", not "I haven't got round to it".
>
> 2/ Switch to Java11 for the next release but not make so many changes
> that we can't easily go back to Java8.
>
> Andy
The discussion on users@
https://lists.apache.org/thread.html/re6bd2d266343a5dffc2b811df2ed63caea07196db42bb929a6b2fb7d%40%3Cusers.jena.apache.org%3E
Points:
* bump to Jena4.
* request to keep a parallel 3.x branch (nice if resourced only if
resourced)
If Jena4, then are there any things we can do which won't significant
impact the timescale - we can take longer of course but I think any
major work item that would need several additional months, and all the
risk of that slipping :-), really must be important.
1/ Mass removal of deprecated - a lot has been deprecated for many
versions so removing it a 4.x seems reasonable. I hope people have been
taking note but code can always return if necessary.
2/ Retire modules or remove code we do not want to migrate to Jena4,
especially as we can still include it again later if there is
unanticipated user demand. Again, a major version jump is a time to be
bold(er); all code has cost.
jena-text-es is a candidate from my point of view. No one is maintaining
it and it is complicated to setup and support.
Andy