Move to Jakarta EE

[hmottestad]

We've already moved JAXB, but there are still a few references to other EE stuff that should be moved to Jakarta. IntelliJ has a migration for this which will hopefully help.

[hmottestad]

We need to update:

• jaxb to 3.0.1

[hmottestad]

After giving this a shot I've decided it's far too much work to make sure that we don't break compatibility with existing application servers.

[erikgb]

@hmottestad Is there any chance we could bring this back on the table, probably in a new major version of rdf4j? I am trying to migrate a spring-boot project (with rdf4j dependencies) to spring-boot 3.x, and it requires the javax -> jakarta migration. So this issue is a total blocker.....

[hmottestad]

@erikgb Last I looked into this it seemed like a fairly large task. Would you be interested in contributing a fix yourself?

Do you know which modules your code depends on? Maybe there is a chance that the scope can be reduced to a smaller part of the RDF4J codebase.

[erikgb]

Would you be interested in contributing a fix yourself?

I could give it a shot.

Do you know which modules your code depends on? Maybe there is a chance that the scope can be reduced to a smaller part of the RDF4J codebase.

We depend on quite a lot, and I don't think this migration can be limited to a part of the codebase. Here is an example of the stack-traces I get:

java.lang.NoClassDefFoundError: javax/xml/bind/annotation/adapters/HexBinaryAdapter
	at org.eclipse.rdf4j.rio.helpers.AbstractRDFParser.createNode(AbstractRDFParser.java:413)
	at org.eclipse.rdf4j.rio.rdfxml.RDFXMLParser.createNode(RDFXMLParser.java:802)
	at org.eclipse.rdf4j.rio.rdfxml.RDFXMLParser.getNodeResource(RDFXMLParser.java:514)
	at org.eclipse.rdf4j.rio.rdfxml.RDFXMLParser.processNodeElt(RDFXMLParser.java:414)
	at org.eclipse.rdf4j.rio.rdfxml.RDFXMLParser.startElement(RDFXMLParser.java:331)
	at org.eclipse.rdf4j.rio.rdfxml.SAXFilter.reportDeferredStartElement(SAXFilter.java:303)
	at org.eclipse.rdf4j.rio.rdfxml.SAXFilter.startElement(SAXFilter.java:234)

[erikgb]

@hmottestad I started on an early draft PR, just to get some overview: #4367

Since spring-boot 3.x and spring 6.x requires Java 17, I suggest we start by bumping the min Java version to Java 17. Which branch should I target for such a change? Have you established a branch for the next major version?

I also think we should fix some deprecation warnings in the codebase, especially those in the Spring area. They will for sure bother us when bumping versions of Spring dependencies.

My local investigation so far indicates that removing the dependency to commons-fileupload is a blocker that will take some time. Multipart is built in in newer version of the Servlet spec, so no need for commons-fileupload, and no new release since 2018 anyway.

Please let me know what you think! Maybe @jeenbroekstra also should share his point of view regarding this potential change? I don't want to spend time on this if the Maintainers are not fully "on board". 😸