[jira] [Created] (JENA-2029) IRILib.filenameToIRI does not add a "/" to files that are directories
Andy Seaborne created JENA-2029: --- Summary: IRILib.filenameToIRI does not add a "/" to files that are directories Key: JENA-2029 URL: https://issues.apache.org/jira/browse/JENA-2029 Project: Apache Jena Issue Type: Improvement Affects Versions: Jena 3.17.0 Reporter: Andy Seaborne IRILib.filenameToIRI does not return a string ending in "/" for a directory which makes resolving other IRIs against this a base potentially go wrong. -- This message was sent by Atlassian Jira (v8.3.4#803005)
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
[jira] [Created] (JENA-2028) Code cleanup
Andy Seaborne created JENA-2028: --- Summary: Code cleanup Key: JENA-2028 URL: https://issues.apache.org/jira/browse/JENA-2028 Project: Apache Jena Issue Type: Improvement Affects Versions: Jena 3.17.0 Reporter: Andy Seaborne Assignee: Andy Seaborne This is a ticket to link to a number of code cleanup changes. It includes removing code that has marked "deprecated" for several releases and isn't use din Jena itself. This is mostly on system APIs, so it should little impact on user application code. The commits identify the areas touched. -- This message was sent by Atlassian Jira (v8.3.4#803005)
