When are you looking to migrate to Jakarta.* / Spring Boot 3? What are your JAXB dependencies?

[rbygrave]

Spring Boot 3 is expected in November and that will use Jakarta.*

Q: When are people looking to migrate their apps to Jakarta.* or Spring Boot 3?

The expected problem when looking at applications making this migration is 3rd party libraries that:

• Have a dependency on javax JAXB
• Do not yet have a version of their library that supports jakarta JAXB

For example:

• PdfBox - https://github.com/apache/pdfbox/blob/2.0/xmpbox/pom.xml#L41
• Sardine - https://github.com/lookfirst/sardine/blob/master/pom.xml#L185-L187 (this is javax jaxb even though it doesn't look like it)

Have you contacted those 3rd party libraries and asked them if they are going to add support for Jakarta JAXB? Do you have a plan for dealing with the case if they don't intend to support Jakarta JAXB / like a fork or javaagent or build time hack?

See: #2835

[rbygrave]

If people are keen enough we could look to release some sort of release candidate from master with the Jakarta PR applied. I don't want to commit to maintaining a long running branch/fork for Jakarta just yet but maybe a periodic ebean-jakarta-RC1 style release if people are keen.

[jnehlmeier]

It will probably take quite some time to upgrade. While I would really like to use newest Jetty there are some libraries that hold me back either because they have no Jakarta version yet and are generally moving slowly or are generally old and would need to be migrated to newer major versions or replaced by some other library (including breaking changes). Of course some of these libraries need JAXB in older versions.

So a time frame to migrate can not be given.

[rbygrave]

So a time frame to migrate can not be given.

My gut feeling is that a lot of folks are in the same position. Still useful to hear it - thanks!!. The priority has to be to support existing applications and right now the feeling is that's going to be the case for a rather long time. Which leads to the thought that it's likely that we will need to "make a Jakarta fork work" for an extended period. I actually maintain a fork (javax.inject and jakarta.inject) for https://github.com/avaje/avaje-inject/ but I definitely want to look to do it better / easier than I do it there (ah, some good thoughts ... ).

[rbygrave]

Ok, maybe a path forward is to "maintain a Jakarta fork" with a twist - the twist being that the fork uses Jakarta JAXB but still uses javax.persistence. It would be better to call it the "Jakarta JAXB fork".

Background:
For avaje-inject (which I maintain) it has the main branch using Jakarta (jakarta.inject) and the fork branch is Javax (uses javax.inject). Maintaining the fork is quite frankly a real pain and the reason it is a pain is because there is jakarta.inject / javax.inject used everywhere ... tests, all the implementation, everywhere !!. This means there is always effort with merging and search n replaces required etc. It's not difficult work per say but it is a pain. That pain is multiplied by the number of changes, size of code base and frequency of release.

But for Ebean:
For Ebean, by sticking to javax.persistence (and to me this makes sense because for any given project its the ORM that depends on the persistence API and we generally don't have 2 ORM's in a single project) ... then jakarata.* changes for ebean only impacts it's JAXB use and we are really really unlikely to get merge conflicts on that anytime soon.

That means, releasing a "JAXB Jakarta fork" for ebean can be:

• create a temporary branch
• merge in the "JAXB Jakarta" PR
• global search and replace the version putting in "jakarta" e.g. 13.11.2 -> 13.11.2-jakarta
• release

Note that I've just released a 13.11.2-beta-jakarta to maven central to confirm that.

The next thought is to check the ebean-migration project for JAXB use and look to move that into the ebean repo as a sub-module (which is probably a good thing to do anyway ... and perhaps do the same for ebean-spring-txn, and maybe we need to do that for ebean-elastic as well?).

The downsides are that it still takes time and that it will confuse people that the "Jakarta fork" still uses javax.persistence. The upside is that new projects adopting Spring Boot 3 can work.

[rPraml]

Hello Rob,

our timeline for jakarta is

• Q1/2023 work out a concept of migration
• Q2/2023 migrate to Java 17
  • check, if application has any incompatibilities (there shouldn't be many)
  • inform customers to upgrade their JVMs
  • but we still use Tomcat 9)
• Q3/2023 our application will run in compatibility mode in tomcat 10
  • it still uses Spring 2.7
  • it will still run on tomcat 9
  • that means, we will provide 2 war files, one with javax and one with jakarta namespace.
  • The second war file is ideally just translated with the jakartaee-migration-tool
• Q4/2023 We use Spring 3.x and we will require tomcat 10
  • everything is fine and everyone is happy

(We planned very conservatively here. And as usual for timelines, these can always deviate greatly from the actual planning.)

Since it's Q1 now, we're already exploring possibilities

• It seems that our war file (that contains ebean/spring 2.7/vaadin/many other frameworks) will run on tomcat 10, if it is translated with the migration tool. A short click test (less than 30min) in this application showed at least no error.
• We are currently investigating, if we can translate the generated jars during maven build.

A quick test shows, that adding this code to the maven pom will generate jakartaee artifacts

      <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>3.1.0</version>
        <executions>
          <execution>
            <id>javax2jakarta</id>
            <phase>package</phase>
            <goals>
              <goal>run</goal>
            </goals>
            <configuration>
              <target>
                <taskdef name="javax2jakarta" classname="org.apache.tomcat.jakartaee.MigrationTask" classpathref="maven.plugin.classpath"/>
                <javax2jakarta src="target/${project.build.finalName}.jar" dest="target/${project.build.finalName}.jar" profile="tomcat"/>
              </target>
            </configuration>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>org.apache.tomcat</groupId>
            <artifactId>jakartaee-migration</artifactId>
            <version>1.0.6</version>
          </dependency>
        </dependencies>
      </plugin>

This could be an option for ebean. Maybe put it in a profile, so you are able to switch between javax/jakarta release.

[rPraml]

A short update
@maTrojak and @jskrobko are currently evaluating, what to do to get our application working.
As already said before, the javax2jakarta transformer seems to do a good job.

But this isn't the long-term way we want to go, so we would need a jakarta-version of every artifact if possible (we only want to use javax2jakarta in exceptional cases)
For most of them, there is already a "fork", but maintaining a fork is relly hard, so the fork has to be generated

Background: For avaje-inject (which I maintain) it has the main branch using Jakarta (jakarta.inject) and the fork branch is Javax (uses javax.inject). Maintaining the fork is quite frankly a real pain and the reason it is a pain is because there is jakarta.inject / javax.inject used everywhere ... tests, all the implementation, everywhere !!. This means there is always effort with merging and search n replaces required etc. It's not difficult work per say but it is a pain. That pain is multiplied by the number of changes, size of code base and frequency of release.

Please take a look at this PR https://github.com/FOCONIS/javax-persistence-api/pull/1
We've added an ant task, that does some search and replace and with only 4 files changed, we can generate "javax-persistence-api" and "jakarta-persistence-api"

But for Ebean: For Ebean, by sticking to javax.persistence (and to me this makes sense because for any given project its the ORM that depends on the persistence API and we generally don't have 2 ORM's in a single project) ... then jakarata.* changes for ebean only impacts it's JAXB use and we are really really unlikely to get merge conflicts on that anytime soon.

I don't like that ebean sticks to `javax.persistence'. Reasons

• Dependency hell (Spring may try to pull jakarta as depencency and it might have to ignored everywhere)
• Having javax.perisistence + jakarta.persistence on the class path is normally not a problem but causes confusion
• 3rd party frameworks may require jakarta
• legal reasons. I have to admit that I don't fully understand the legal aspects of renaming javax->jakarta. But I could imagine that at some point a lawyer will come along, who has no idea about programming, but will piss you on the leg because of something like this.

That means, releasing a "JAXB Jakarta fork" for ebean can be:

... automatically translated by an ant-task

We've analyzed, that we have to translate at least "ebean-api" and "ebean-core",
So we plan to add a module "ebean-core-jakarta" and "ebean-api-jakarta" and maybe an "ebean-bom-jakarta"
(we would have to do the same trick for "javax.xml" for ebean-autotune and so on as already done in #2837)

We need only a few "glue" code to get other modules to compile (e.g. we would need a io.ebean.GeneralPersistenceException that inherits either from javax.persistence.PersistenceException or from jakarta.persistence.PersistenceException,
so all other modules will get a "provided" dependency to "ebean-core" and "ebean-api" and if you include ebean in your application you can decide, if you want to provide "ebean-core" or "ebean-core-jakarta"

The replaced files may be .gitignored, so you ideally have only some additional pom files, that do the translation.

There is still some work to do, especially the Ebean-Agent and the QueryBean generators are more than just to replace the imports.
It might be possible, at least for the agent, that it becomes "bilingual" - that means it will enhance javax.perisitence.@Entity and jakarta.perisitence.@Entity

So for Ebean 13, it should be easy - with just the additional compile time of the modules - to maintain a javax and jakarta version.
With Ebean >=14 we might drop the javax support

Roland

[rPraml]

Announcement

foconis has decided to sponsor Rob for implementing the jakarta support in ebean.
Sponsoring Ebean is important for us, as this is one of the most important framework for our current application developement.

As soon as there are first releases with jakarta support, we will test them and provide feedback. It would be great if we could find other people to try out the new jakarta support and give feedback.

Roland

[rbygrave]

Thanks to Foconis we have moved the effort forward enough to have a plan that I think is good and sustainable over the long term.

Plan outline:

• We will release both a javax and jakarta version of ebean for every release.
• For each release we release a version 'X' and a 'X-jakarta' of virtually all the modules (all the modules in the main ebean repo).
• ebean-agent + ebean-maven-plugin + maven tile + gradle plugin all work with both javax and jakarta. We might release -jakarta versions of these if that reduces some confusion.
• The IntelliJ plugin works with both javax and jakarta
• The notable modules we will not release a jakarta version for at this stage are ebean-migration, ebean-elastic, ebean-hazelcast. Note that these work with both javax and jakarta versions and currently have a different release cadence. We might adjust this later if this proves confusing for people.

Implementation:

• The ebean master branch will initially stay using javax (but we might agree to swap the master to jakarta at some point later)
• There will not be a 'jakarta' git branch
• We will use scripts to automatically convert from javax to jakarta (and vice versa). This removes the pain points around maintaining a fork on a branch.

Releasing:

Releasing to maven central involves the extra steps of:

• javax-to-jakarta conversion
• change version adding -jakarta suffix
• mvn deploy X-jakarta to central

The benefits of this approach is that we will be able to sustain both a javax and jakarta "fork" over a long time (years). All the tests run with both javax and jakarta so we have good confidence in both releases that we put into central. It should be pretty easy for people to use and understand correctly.

The people who maintain a fork of ebean will need to agree if and when we swap the master branch over to use jakarta (and then use the jakarta-to-javax conversion). As fork maintainers adopt jakarta they are likely to want to have the ebean master branch also on jakarta as that just makes it easier to see diffs and removes the extra jakarta-to-javax conversion that would be required. So at some point it's likely that we swap over the ebean master branch to use jakarta (and then our 2nd release uses the jakarta-to-javax conversion). Regardless of what we use on master we will still continue to release both versions and we will have to do that for quite a long time (years).

[rbygrave]

We have released version 13.14.0 and 13.14.0-jakarta and we can consider the Jakarta version a production version. Anyone using the jakarta version can raise an issue if it doesn't work etc.

I have converted over a small application to use 13.14.0-jakarta and it's all working as expected and the release process is pretty good. There is some outstanding thoughts / tasks:

• Ponder releasing jakarta versions of ebean-maven-plugin and the maven tile (as these typically share the same version. This really means improving the release process for these so that it's fewer manual steps / fully scripted.
• Consider moving the ebean-spring-txn into ebean so that it's released each time with the other ebean modules