My immediate question would be - Hibernate has some dependencies. I might be looking at an out-of-date version, but that could include jboss-logging, jandex and others. What's the license on those? At a quick glance, it -looks- ok, but I think its worth enumerating what would actually change in the artifacts we distribute to make sure we're ok from a licensing perspective.
>From the perspective of moving away from OpenJPA, I'd be interested in some data, and looking at it with an OpenJPA centered view: * I assume the change is motivated because OpenJPA is behind other implementations from a spec compliance perspective. How big is the gap? Should we run the TCK and have a look? (I'm hoping to get some time to do TCK work shortly, so might be a good opportunity for me to look) * Lack of resources - if we know what's needed, could we find the time/people? * What's OpenJPA's own view on the project status? It looks like there's some activity, a release within the last 12 months, and a new committer within the last 6 months. https://whimsy.apache.org/board/minutes/OpenJPA.html OpenJPA has been the default persistence provider since forever (or at least for whole time I've been involved with TomEE, which is closing in 20 years now). If TomEE decides not to use OpenJPA, how does that decision impact OpenJPA? I'm definitely getting old, but I remember presenting TomEE for the first time at JAX London in 2011 with David Blevins. It was the All Apache stack, where Tomcat is top dog. Here's the slides: https://tomee.apache.org/presentations/2011_JavaOne_Apache_TomEE_Java_EE_6_Web_Profile.pdf - you can probably find the video on YouTube. Having different implementations of the specs gives a bit of diversity in the Jakarta EE world. All the app servers could theoretically use the reference implementations of everything, but I think that potentially leaves little to distinguish them, and reduces innovation opportunity. David can no doubt tell stories of functionality that is now part of the spec, but started as an experiment in OpenEJB. We've seen a move away from the Geronimo MicroProfile implementations to the reference implementation (SmallRye). Similar story there - the implementation fell behind, and not enough people to fill the gap. If the TomEE community decided to move to Hibernate and away from OpenJPA, I would understand. But I'd be sad about it. It would feel like the 'All Apache stack" is now the 'A bit of Apache stack". 20 years ago, I'd have been up for some all-night hacking on OpenJPA - unfortunately, personal circumstances make that difficult now. I can try and get some $work time on it. I'm willing to try and help out on OpenJPA, but I don't know how big the task is at the moment. Jon On Wed, Oct 15, 2025 at 1:15 PM Richard Zowalla <[email protected]> wrote: > Hi, > > I would love to hear some additional feedback (also from within the TomEE > PMC) > > Any thoughts on JPA in TomEE @ Mark, Markus, David, JL or Jon? > > Gruß > Richard > > On 2025/09/26 08:29:25 Richard Zowalla wrote: > > Hi all, > > > > I’d like to start a discussion about the future of OpenJPA in TomEE, > specifically whether it’s time to consider replacing it with Hibernate. > > > > Hibernate 7 is now ASLv2 licensed, fully implements the latest spec > features, and already supports Jakarta Data for EE 11. This puts it in a > strong position to meet our needs moving forward, especially as we look > toward TomEE 11. > > > > By contrast, OpenJPA has struggled to keep up, and realistically we > don’t appear to have enough development resources to build and maintain an > ASF-only implementation of Jakarta Data. In fact, we made a similar > decision when we gave up the ASF-only spec implementations some time ago. > > > > Of course, anyone who prefers to stay with OpenJPA can still swap it in, > but from my perspective, I believe we should seriously consider whether > Hibernate should become the default going forward. > > > > I’d like to hear your thoughts, both on the practical implications for > TomEE and the overall direction we should take. > > > > Gruß > > > > Richard >
