Support for Java 17?

[ralfhergert]

SpringBoot 3.0 was released these days making the switch from Java 11 to Java 17. Biggest impact might be all the javax-libraries which are now moved to jakarta.

Any plans when this project will start to support Java 17?

[rjrudin]

Our current plan is to address Java 17 in a 6.x release, once 6.0.0 is released along with MarkLogic 11. Depending on the issues / incompatibilities we run into, that 6.x release may happen fairly soon after 6.0.0 is released. We are also hoping that it's possible to continue supporting Java 8 and Java 11 at the same time, but we haven't done enough analysis and testing yet to know if that's feasible - we're presuming it will be heavily influenced by any issues with Java Client dependencies.

[rjrudin]

Also @ralfhergert - if this is in support of a particular customer (or customers), can you file a support ticket that identifies those customers? We have such a ticket open already, this would just be a private way to communicate who those customers are so that we know who's most interested in this.

[ralfhergert]

@rjrudin Sure, I'll create a support ticket.

[rjrudin]

@ralfhergert After some testing and analysis, I believe this is largely a docs gap/bug for the Java Client - i.e. if you're on Java 11 or higher and you touch any part of the Java Client that depends on the "old" JAXB (the javax.xml.bind package), you need to include those dependencies yourself. They're included in Java 8, deprecated in 9 and 10, and removed in 11.

#1471 has an update to the README to make this clear. I've verified that when I run a test using e.g. JAXBHandle on Java 17, it fails with an expected class-not-found-error. And then when those old JAXB dependencies are included, the test runs fine.

Are you able to try out including those 3 dependencies in your project? Or, are you running into a different error?

We will still want to formally announce support for Java 17, but based on the above, all aspects of the Java Client appear to function correctly as long as the old JAXB dependencies are available on the classpath.

[rjrudin]

@ralfhergert You can find the instructions now in the README on our develop branch - https://github.com/marklogic/java-client-api/blob/develop/README.md#including-jaxb-support . If you're able to try this out, please let me know. The only reason I can't see this working is if a javax.xml.bind implementation of JAXB does not work on Java 17, but at least the glassfish implementation seems to perform just fine (all of the Java Client tests, which includes dozens of tests using JAXB, pass on Java 17 with the glassfish implementation).

[ralfhergert]

@rjrudin In #1471 you may want to use jakarta.xml.bind:jakarta.xml.bind-api:2.3.3 instead of javax.xml.bind:jaxb-api:2.3.1 to be more future proof, since javax.xml.bind:jaxb-api is deprecated and no longer maintained (since 2018).

In fact JAXB has been moved into the Eclipse Jakarta project. Thus classes in the package javax.xml.bind (like javax.xml.bind.JAXBContext) have been moved into the package jakarta.xml.bind in 2020 (with release of JakartaEE9).
See: jakartaee/platform#133

[rjrudin]

Thanks @ralfhergert - yes, our plan is to upgrade the Java Client soon to depend on the jakarta library instead of the deprecated javax library (we've done a prototype of that and it appears to be a straightforward upgrade). Until then, our testing has shown that the javax library functions correctly on Java 17 and thus JAXB support within the Java Client functions correctly as well on Java 8, 11, and 17. FWIW, we tested it as well on an implementation of Java 19 and all tests passed there too. So that's good news in the short term, but yes - we'll be upgrading to jakarta soon, most likely in the early 6.x timeframe.

[rjrudin]

Going to close this ticket as the README now describes how to use the Java Client with JAXB on Java 17. Switching to JAXB 3 or 4 makes sense at some point in the future, but we'll track that separately.