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?

[chrisdennis]

No idea, my experience with ORMs is so 'inside out' that I don't have a clear picture on that kind of thing. Incidentally the PR that overhauls the build system to add support for what you want is here: #2962

I've tested it locally by migrating the hibernate-jcache module to Jakarta JPA and using the new variant and it seems to work fine (tests pass in that module at least). Once this PR is merged I'll cut a pre-release and then PR my integration of this in to the Hibernate wip/6.0 branch.

[sebersole]

That would be amazingly awesome!

We'd be able to re-enable "real" cache testing - atm we use our internal-only, intended for testing cache impl which is not really great

[chrisdennis]

I've created hibernate/hibernate-orm#4380 to cover (test?) integrating these changes in to Hibernate.

[thomass4t]

Hello,
I would like to kindly ask if there is any scheduled date for a jakarta-compatible version.
Are there any blocking issues or is it just a matter of time?
Thanks! Thomas

[chrisdennis]

There is an early alpha of this published under version 3.10.0-alpha0. There is no set schedule for a GA of that right now, but there are no "blocking issues" either. The only thing really holding it up at the moment is finishing up the integration of the changes in the various internal downstream builds, and bringing the clustered components that Ehcache 3 depends on to a stable point.

[thomass4t]

Thanks for the quick reply! I will give it a try :)

[thomass4t]

The ConfigurationParser.java still has some dependencies on javax.xml.bind... within ehcache-3.10.0-alpha0.jar
e.g. import javax.xml.bind.Marshaller;
Maybe some issues with building the package because there is a java-source file with jakarta instead of javax.xml.
I think I need to wait a bit till a release is available.
Thanks for your support! Thomas

[chrisdennis]

Just one thing to check. The 'default' artifacts still use javax packages. The Jakarta version are variants, to depend on them in Maven you would need:

<dependency>
    <groupId>org.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>3.10.0-alpha0</version>
    <classifier>jakarta</classifier>
</dependency>

or in Gradle (where everything will work more transparently)

implementation('org.ehcache:ehcache:3.10.0-alpha0') {
    capabilities {
        requireCapability("org.ehcache:ehcache-jakarta")
    }
}

Note: I typed the above from memory... I probably put in a bunch of typos and/or mistakes.

[thomass4t]

Ah.... now it looks better. Thanks for the hint :)

[snicoll]

@chrisdennis FYI spring-projects/spring-boot#28800 (comment)

[chrisdennis]

ehcache-xml, ehcache-transactions and ehcache now have Jakarta variants that can be selected using either a capability requirement in Gradle or using a classifier in Maven.

[snicoll]

Very nice, thanks @chrisdennis!