Re: Preparing for Jena5 - API deprecations

2023-07-03 Thread Andrii Berezovskyi
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

2023-07-03 Thread Andy Seaborne

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