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
