Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to Jakarta EE #3559

Open
hmottestad opened this issue Dec 30, 2021 · 11 comments
Open

Move to Jakarta EE #3559

hmottestad opened this issue Dec 30, 2021 · 11 comments
Assignees
Labels
🛠️ tech debt code refactoring, deprecation, and other technical debt tasks

Comments

@hmottestad
Copy link
Contributor

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 hmottestad added the 🛠️ tech debt code refactoring, deprecation, and other technical debt tasks label Dec 30, 2021
@hmottestad hmottestad added this to the 4.0.0 milestone Dec 30, 2021
@hmottestad hmottestad self-assigned this Dec 30, 2021
hmottestad added a commit that referenced this issue Dec 30, 2021
Signed-off-by: Håvard Ottestad <hmottestad@gmail.com>
@hmottestad
Copy link
Contributor Author

We need to update:

  • jaxb to 3.0.1

@hmottestad hmottestad removed this from the 4.0.0 milestone Dec 30, 2021
@hmottestad hmottestad added the wontfix issue won't be fixed (close reason) label Dec 30, 2021
@hmottestad
Copy link
Contributor Author

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
Copy link
Contributor

erikgb commented Jan 17, 2023

@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
Copy link
Contributor Author

@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.

@hmottestad hmottestad reopened this Jan 17, 2023
@hmottestad hmottestad removed the wontfix issue won't be fixed (close reason) label Jan 17, 2023
@erikgb
Copy link
Contributor

erikgb commented Jan 17, 2023

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
Copy link
Contributor

erikgb commented Jan 18, 2023

@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
Copy link
Contributor Author

@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
Copy link
Contributor

erikgb commented Jan 18, 2023

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

@jetztgradnet
Copy link

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
Copy link
Contributor

erikgb commented Feb 3, 2023

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

@aschwarte10
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🛠️ tech debt code refactoring, deprecation, and other technical debt tasks
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants