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 <a...@apache.org> 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
