Re: Exploring Hibernate 6/7 support for tapestry-hibernate

--00000000000082dfb8065262f409
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Chris!

For my company, Hibernate provides some niceties over a pure JPA approach.
That=E2=80=99s why updating it is definitely on my short list of things to =
tackle.

One of the things that kept us from experimenting with newer versions was
that 6 dropped the Criteria API, which we had heavily used until now.
We=E2=80=99re still transitioning our DAOs to the JPA CriteriaBuilder API, =
but plan
to switch to a newer version as soon as that=E2=80=99s done.

Which version to target, though... that=E2=80=99s not an easy question to a=
nswer,
due to Tapestry=E2=80=99s minimum JDK requirements.

For the javax branch, that would mean 5.6.
I remember there was a bytecode-generation issue in the past that prevented
further versions.
But at that point in time we already used a fork, so we=E2=80=99d need to c=
heck
with the current 5.10 infrastructure again, if that problem still exists.

For the jakarta branch, 6.6 is the final version with Java 11 support.
That could mean making 6.6 the new baseline.

However, I=E2=80=99d like to see a 7.4 (current release) or even an 8 (dev =
version)
variant, which would require Java 17.
Introducing a tapestry-hibernate7 and tapestry-hibernate8 later might be a
possibility, but would create additional modules to manage, and might be a
better fit for the community umbrella I talked before on the mailing list.

And we still got the elusive =E2=80=9CSession returns null=E2=80=9D issue t=
hat I could
never consistently reproduce on my end=E2=80=A6
https://issues.apache.org/jira/browse/TAP5-2754
This might require a rewrite of how Session is used, as the
PropertySessionBuilder is not capable of intercepting the intricate type
hierarchy behind Session.

These are all just my personal ideas how to handle it, there's no "set in
stone" roadmap yet.

Cheers
Ben

On Sun, May 17, 2026 at 12:18=E2=80=AFPM Christopher Dodunski (Tapestry) <
[email protected]> wrote:

> Hi all,
>
> I=E2=80=99ve been looking into the current state of tapestry-hibernate an=
d
> tapestry-hibernate-core, which currently target Hibernate 5.4.32. Given
> that Hibernate 5 is now quite old, I wanted to raise the question of
> whether there has been any recent discussion or ongoing work around
> supporting Hibernate 6 or 7.
>
> After reviewing the modules, they appear to be relatively lightweight
> integration layers focused mainly on:
>
>    * SessionFactory/bootstrap integration
>    * request/session lifecycle management
>    * transaction handling (@CommitAfter, etc.)
>    * IOC wiring and entity scanning
>
> At first glance, this does not appear to require a complete rewrite,
> although the Hibernate 5 to 6 transition is obviously substantial due
> to:
>
>    * Jakarta migration (javax.persistence =E2=86=92 jakarta.persistence)
>    * bootstrap/API changes
>    * transaction/session SPI changes
>    * removal/refactoring of some Hibernate internals
>
> My assumption is that most of the real work would likely be:
>
>    1. achieving Hibernate 6 compatibility first
>    2. stabilizing lifecycle/transaction behavior
>    3. then moving on to Hibernate 7
>
> Since Tapestry itself has already undergone the recent javax to jakarta
> migration, I=E2=80=99m curious whether anyone has already:
>
>    * experimented with upgrading the Hibernate modules
>    * created a branch or proof-of-concept
>    * investigated compatibility blockers
>    * or discussed a roadmap for this work
>
> If not, I=E2=80=99d also be interested in hearing whether the community s=
ees
> value in modernizing the Hibernate integration versus potentially
> steering users toward thinner JPA-only integration approaches.
>
> Kind regards,
>
> Chris.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

--00000000000082dfb8065262f409--