Re: Preparing for Jena5 - API deprecations
+1. Clean it out! Adam On Mon, Jul 24, 2023, 1:36 PM Andy Seaborne wrote: > Another item for deprecation-removal. > > Model.query(Selector) and all the Selector code. > > Nowadays, JDK java can cleanly do filtering and there is SPARQL for > anything more complex. > > Andy >
Re: Preparing for Jena5 - API deprecations
Another item for deprecation-removal. Model.query(Selector) and all the Selector code. Nowadays, JDK java can cleanly do filtering and there is SPARQL for anything more complex. Andy
Reification [Was: Preparing for Jena5 - API deprecations]
Reification is only supported in the Model API, not Graph. It's already simpler than it was when first introduced, when it had 3 different modes. The complexity on storage was huge. https://www.hpl.hp.com/techreports/2003/HPL-2003-266.pdf Reification subsequently got simplified to library code in the Model API which corresponds to the original "Reification standard mode". https://jena.apache.org/documentation/notes/reification_previous.html See ReifierStd, which is all static functions. (There are no "hiddenTriples" - that was an old feature) Andy
Re: Preparing for Jena5 - API deprecations
Hi Andrew, None - it only affects Fuseki. While it is generally referred to as the javax.* transition, it is not all of java. It's the javax that are part of J2EE. Other javax are in the JDK. https://blogs.oracle.com/javamagazine/post/transition-from-java-ee-to-jakarta-ee There is one I haven't looked at yet: javax.xml.bind -> jakarta.xml.bind which is local to org/apache/jena/datatypes/xsd/XSDhexBinary.java There may be dependency changes that have an effect if an app gets them recursively via Jena. For Fuseki: javax.servlet.* -> jakarata.servlet.* Here's a commit that makes the change https://github.com/afs/jena/commit/c91abd94562d4c508ee0deedda3ed9f4d872a818 The only non-Fuseki changes are in: jena-integration-tests/src/test/java/org/apache/jena/test/conn/StringHolderServlet.java -- defines servlet jena-permissions/pom.xml -- because of shiro pom.xml -- version of Jetty, shiro dependency management Andy On 03/07/2023 19:32, Andrii Berezovskyi wrote: Hello Andy, May I ask if there is any impact on the non-Fuseki users of Jena in regard to the planned javax.* -> jakarata.* migration? –Andrew. On 3 Jul 2023, at 14:57, Andy Seaborne wrote: So far we have: 1/ Java21 is due to be released September 2023 and be a LTS release. 2/ javax.* -> jakarata.* 3/ Drop a separate JSON-LD 1.0 subsystem. 4/ Term graphs One more thing I'd like to suggest for Jena5 is simplification. Look for code/features that are now out of date because of where the standards have gone. Two are: A/ LiteralLabel It may be possible to merge this Node_Literal itself which, together with generally simplifying the Node hierarchy, makes the system There are what look like matters from RDF 1.0 WG in the code; RDF 1.1 makes RDF Terms simpler and clearer. While this is in an "impl" package, it also features in some Model API calls. B/ The "is well formed" flag ... also called "isXML" in some places at the node level despite the fact it is used for things other than XML. This does not need to be done when creating Node_Literals. With term graphs, and parsing, value evaluations checking isn't required all the time but it adds costs to the critical path. There is a control JenaParameters.enableEagerLiteralValidation which is false and which controls how to respond to bad literals. To allow for A and B, I'd like to deprecate API calls that involve them. It may turn out some parts need to be kept - I've only done an initial pass over the code - but I think it is better to warn now and not simply put in changes at Jena5 with no advance notice. Andy
Re: Preparing for Jena5 - API deprecations
Hello Andy, May I ask if there is any impact on the non-Fuseki users of Jena in regard to the planned javax.* -> jakarata.* migration? –Andrew. On 3 Jul 2023, at 14:57, Andy Seaborne wrote: So far we have: 1/ Java21 is due to be released September 2023 and be a LTS release. 2/ javax.* -> jakarata.* 3/ Drop a separate JSON-LD 1.0 subsystem. 4/ Term graphs One more thing I'd like to suggest for Jena5 is simplification. Look for code/features that are now out of date because of where the standards have gone. Two are: A/ LiteralLabel It may be possible to merge this Node_Literal itself which, together with generally simplifying the Node hierarchy, makes the system There are what look like matters from RDF 1.0 WG in the code; RDF 1.1 makes RDF Terms simpler and clearer. While this is in an "impl" package, it also features in some Model API calls. B/ The "is well formed" flag ... also called "isXML" in some places at the node level despite the fact it is used for things other than XML. This does not need to be done when creating Node_Literals. With term graphs, and parsing, value evaluations checking isn't required all the time but it adds costs to the critical path. There is a control JenaParameters.enableEagerLiteralValidation which is false and which controls how to respond to bad literals. To allow for A and B, I'd like to deprecate API calls that involve them. It may turn out some parts need to be kept - I've only done an initial pass over the code - but I think it is better to warn now and not simply put in changes at Jena5 with no advance notice. Andy
Preparing for Jena5 - API deprecations
So far we have: 1/ Java21 is due to be released September 2023 and be a LTS release. 2/ javax.* -> jakarata.* 3/ Drop a separate JSON-LD 1.0 subsystem. 4/ Term graphs One more thing I'd like to suggest for Jena5 is simplification. Look for code/features that are now out of date because of where the standards have gone. Two are: A/ LiteralLabel It may be possible to merge this Node_Literal itself which, together with generally simplifying the Node hierarchy, makes the system There are what look like matters from RDF 1.0 WG in the code; RDF 1.1 makes RDF Terms simpler and clearer. While this is in an "impl" package, it also features in some Model API calls. B/ The "is well formed" flag ... also called "isXML" in some places at the node level despite the fact it is used for things other than XML. This does not need to be done when creating Node_Literals. With term graphs, and parsing, value evaluations checking isn't required all the time but it adds costs to the critical path. There is a control JenaParameters.enableEagerLiteralValidation which is false and which controls how to respond to bad literals. To allow for A and B, I'd like to deprecate API calls that involve them. It may turn out some parts need to be kept - I've only done an initial pass over the code - but I think it is better to warn now and not simply put in changes at Jena5 with no advance notice. Andy
