Any plans to offer a Jakarta version?

[sebersole]

In playing around with migrating Hibernate to Jakarta Persistence APIs I ran into trouble with our hibernate-jcache module. The only hang up I saw was that ehcache3 uses JAXB which would need to be updated to use Jakarta's JAXB apis/impls.

Having done this for Hibernate I can offer some help/guidance. Let me know

[chrisdennis]

There are multiple things in motion in my periphery that would probably benefit from this migration, so it is likely to happen, but I can't offer a concrete timeline. That said I know of no reason why this isn't a simple migration, the disruption to user is a little harder to quantify. Given we don't bleed our usage out through API I could even in a pinch buy doing this in a dot release, but that might perturb some users.

[sebersole]

Hey @chrisdennis long time!

I have a set of Gradle tasks that leverage the Jakarta transformer-tool to simplify this. Supposedly you can run it from the command line as well, but I have never had luck with that. The more important piece are the "rule" files which control the transformation. We have these as part of Hibernate as well.

[sebersole]

If you want to take a peek..

• the tasks are at https://github.com/hibernate/hibernate-orm/tree/wip/6.0/hibernate-orm-build/src/main/java/org/hibernate/orm/jakarta
• the rules are at https://github.com/hibernate/hibernate-orm/tree/wip/6.0/rules

[chrisdennis]

I've hacked up a branch: https://github.com/chrisdennis/ehcache3/tree/jakarta-jaxb that provides what I think you need. Getting this integrated is complicated though for a multitude of reasons:

1. We need to decide if we want to push the JTA support to use Jakarta JTA too (and how this relates to the weird Java SE JTA / Jakarta split).
2. We need to decide if this becomes a secondary set of artifacts, or if we version bump and hard cut.
3. If we version bump do we take the opportunity to drop JDK 8 support (which I think you guys would not like?).
4. Internally at Software AG this is also complex since Ehcache gets integrated in to a container environment where the JAXB implementation is currently centrally provided. I'd need to jump through some internal hoops to make sure that having both JAXB implementations on the classpath is okay. In a twist of fate this also might result in a cyclic dependency since there is an internal effort afoot to update to [Glassfish 6, Spring 6, Tomcat 10].

I've kicked off the effort to push on this stuff internally. If I doesn't look like it'll get resolved quickly then I'll probably (at least temporarily) move to a split artifact set (e.g. ehcache-3.9.x-jakarta.jar) in the same way that Hibernate has.

[sebersole]

For what it is worth, I really don't care about it getting "integrated" if by that you mean some specific environment. Just having it published is more than enough for us.

In the meantime, we are releasing our Beta1 without support for JCache+Ehcache because we cannot test the hibernate-jcache module.

[chrisdennis]

Sorry... by integrated I meant merged in to main. The current plan is for us to take the same path Hibernate has and publish jakarta classifier variants for ehcache, ehcache-xml and probably ehcache-transactions. I plan to take that on this week but my main dev machine took a (figurative) flying leap off a cliff this morning so P1 is that right now.

[sebersole]

Aww, would have been a great story if that were literally flying 😆

For what it is worth, with this 6.0 release of Hibernate we have made the switch to Jakarta at source level. After this Beta we will work on the opposite - publish *-javaee variants

[sebersole]

Any luck getting a Jakarta-compatible release? Even a SNAPSHOT would be great for now.

Additionally, since y'all know JCache well, can you explain the optional dependency on CDI? The JCache build says:

        <!--This is only needed if you are using a CDI based implementation of the annotations support.
            In CDI 1.1. we should be able to remove this dependency completely. -->
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <version>1.0-SP4</version>
            <scope>provided</scope>
            <optional>true</optional>
            <exclusions>
                <exclusion>
                    <artifactId>jsr250-api</artifactId>
                    <groupId>javax.annotation</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>jboss-interceptors-api_1.1_spec</artifactId>
                    <groupId>org.jboss.spec.javax.interceptor</groupId>
                </exclusion>
                <exclusion>
                    <artifactId>javax.inject</artifactId>
                    <groupId>javax.inject</groupId>
                </exclusion>
            </exclusions>
        </dependency>

What does "annotations support" mean here? What does the CDI 1.1 (which has come and gone) comment mean?

[chrisdennis]

I've been working this on and off in the last couple of weeks. It's gotten tied up in a long standing Gradle upgrade task and I've run in to some Gradle issues that have held me up. I'm hoping to be done by the end of the week. I have it working locally, including updating the hibernate-jcache module to use the new module and all the tests run clean (if that's any solace).

There's a bunch of stuff under javax.cache.annotation for doing annotation based caching injection - so I'm guessing this is tied to that. I will confess to not paying much attention to what was going on with this corner of the spec though. I was more focussed on trying to make sure the core stuff didn't have glaring flaws in it (apologies for failing on that front).

[sebersole]

Wow, thanks for the quick reply @chrisdennis !

Ok, so it is only related to use of caching-specific annotations for CDI-based injection. How common, if you know, is that in second-level caching for ORM providers?