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". 😸

[hmottestad]

@erikgb Thanks for starting on this :)

Last autumn we had a developer meeting and discussed the next major release (5.0.0). We decided to stick with Java 11 as the minimum requirement for the time being. Moving to Java 17 is definitely something we want to do, but at the moment it would be a blocker for some of our stakeholders.

[erikgb]

@hmottestad I opened #4370 to address an issue that I think could be resolved before the migration. Please add your comments.

[jetztgradnet]

We are also moving our application to JakartaEE and that JAXB HexBinaryAdapter is the main blocker currently.
As we do not run in a "full" JEE/JakartaEE application server we might get away with simply loading JAXB in addition to the Jakarta equivalent, but that's at least not the preferred way.
We are not using the "web parts" (i.e. from the workbench), so do not require a fixed solution deciding on JEE or Jakarta EE for that, but it would be great of there was a way to simply use the main RDF4J libraries in either setting.

Maybe we can even replace that HexBinaryAdapter with something inline? The actual implementation of that method is as simply as this (javax.xml.bind.DatatypeConverterImpl.printHexBinary(byte[]) called from javax.xml.bind.annotation.adapters.HexBinaryAdapter.marshal(byte[])):

    private static final char[] hexCode = "0123456789ABCDEF".toCharArray();

    public String printHexBinary(byte[] data) {
        StringBuilder r = new StringBuilder(data.length * 2);
        for (byte b : data) {
            r.append(hexCode[(b >> 4) & 0xF]);
            r.append(hexCode[(b & 0xF)]);
        }
        return r.toString();
    }```

[erikgb]

@jetztgradnet That is a great suggestion. I think we need to isolate the javax/jakarta dependencies.

[aschwarte10]

@erikgb , @hmottestad : for your awareness, the aspect of Java XML Bind is now extracted into its own ticket #4421