Impact of Jakarta.* - Spring Boot 3, Nov 2022

[rbygrave]

Raising this as a discussion point. Very shortly, around Nov 2022 Spring Boot 3 is expected with Java 17 and Jakarta.* based dependencies.

Is that going to work with Ebean?

persistence-api : No change expected here. Ebean ORM effectively owns these classes so no impact from Spring Boot upgrade. ebean-spring-txn : Folks using Spring managed transactions via ebean-spring-txn. Yes, we do use a deprecated class that might be removed. Easy to resolve, no major issue expected.

Jakarta JAXB : Unfortunately I expect this to be a real problem. The TLDR is that javax JAXB isn't compatible with jakarata JAXB and so when apps make this jump ALL libraries that depend on JAXB must also make this jump to Jakarta. If an application has a 3rd party library that uses javax JAXB and that library does NOT have a version that supports jakarta JAXB then that app will have some effort to resolve that.

For Ebean, we use JAXB in DB Migrations (extremely common) and also Autotune (rarely used). We have held off migrating to Jakarta JAXB due to the incompatibility this causes. We actually bumped to jakarta JAXB, hit these issues, investigated and decided to revert back to javax JAXB. Refer: https://github.com/ebean-orm/ebean/pull/2722

Q: Will Ebean maintain a fork due to the incompatibility in JAXB? A: I really really want to avoid that if at all possible.

Q: Are there any other issues other than JAXB? A: We have optional and minor use of javax.servlet (provides the option to shutdown ebean when servlet context is shutdown) and JTA Transaction but these will not be a major issue to deal with and will not require a fork.

Refer: https://github.com/ebean-orm/ebean/pull/2722 Refer: https://github.com/ebean-orm/javax-persistence-api/issues/8

[rPraml]

FYI: We don't have a timeline yet when and how we go to Jakarta.*

Q: Will Ebean maintain a fork due to the incompatibility in JAXB? A: I really really want to avoid that if at all possible.

Other projects do so (logback e.g.). And yes, I can understand that you really really want to avoid this. We have the luck, that only 3 sub-modules are affected. So I see the following options:

• Bump ebean to the next major version (14) and use jakarta everywhere. Others can still use version 13.x of autotune, ddl-generation and external mapping. The API between these modules should be very mature, so this shouldn't be the problem. I also think the modules itself are mature. (Ok, we occasionally fix small bugs in db-migration) This is the less effort, just keep the API compatible (and maybe the one or other backport is needed)

• Simply copy the affected modules, so we have a "-java" and "-jakarta" module in the master branch. This means duplicate code, which may cause maintenance problems in the future.

• Do the translation automatically in the maven build (e.g. https://rmannibucau.metawerx.net/move-from-javax-to-jakarta-with-apache-tomee-9-2.html - I didn't check, if that really works!) and move the two artifacts separately to mvncentral