Re: SDB [was: Java 8 or 11?]
+1! Adam On Wed, Jan 27, 2021, 4:31 PM Bruno P. Kinoshita 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 < > a...@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, aj...@apache.org wrote: > >> Is SDB perhaps another candidate for retirement? > >> > >> Adam > >> > >> On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne 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?]
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 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, aj...@apache.org wrote: >> Is SDB perhaps another candidate for retirement? >> >> Adam >> >> On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne 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?]
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, aj...@apache.org wrote: Is SDB perhaps another candidate for retirement? Adam On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne 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
jena-iri [was: Java 8 or 11?]
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: Java 8 or 11?
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, aj...@apache.org wrote: Is SDB perhaps another candidate for retirement? Adam On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne 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?
Is SDB perhaps another candidate for retirement? Adam On Wed, Jan 20, 2021, 2:21 PM Andy Seaborne 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?
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?
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?
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 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 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?
On Fri, 8 Jan 2021 at 14:33, Martynas Jusevičius 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 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?
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 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?
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?
+1 Yep, we've been moved over to Java 11 for a while now Rob On 03/01/2021, 10:39, "Dr. Chavdar Ivanov" wrote: +1 -Original Message- From: aj...@apache.org Sent: Saturday, 2 January, 2021 17:57 To: dev@jena.apache.org; Bruno P. Kinoshita 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 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 < > a...@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?
+1 -Original Message- From: aj...@apache.org Sent: Saturday, 2 January, 2021 17:57 To: dev@jena.apache.org; Bruno P. Kinoshita 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 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 < > a...@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?
+1. This will only get more pressing with time. Adam On Fri, Jan 1, 2021, 8:36 PM Bruno P. Kinoshita 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 < > a...@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?
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 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?
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 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 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?
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 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
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
