Hi all, as a consequence of having moved all Java EE technologies to the Jakarta EE project at the Eclipse foundation, the API needs to change so to address the Oracle trademark requirements. The new JPA project lives here: - https://github.com/eclipse-ee4j/jpa-api For context, to make it simpler for people to adopt the new API the Jakarta EE team decided to not allow any other change to the API; this would make it possible for people to migrate their existing code bases by running a simple "search and replace all". This implies that even though it's a new major version, it's sadly not a good time to challenge any API or spec working as this is intentionally frozen. And (our very own!) Scott Marlow helped with the primary change, which you can see here having quite an impact: - https://github.com/eclipse-ee4j/jpa-api/pull/231 It's just a small change of renaming all packages "javax.persistence" to "jakarta.persistence" .. but it has wide impact all over. We should start thinking how to make support for JPA 3 happen in Hibernate ORM; there's of course many options, but we need to take into account some points: 1)We can't spend years of brilliant minds on this 2)We don't want to make the migration too hard to users 3)We normally promise backwards compatibility within minor releases of our projects 4)While Hibernate ORM 6 is making great progress, it's a very large quest to finish it. It's not wise to try to time-box it, while we might need to deliver JPA 3 at some (TBD) reasonable deadline. 5)Whatever we do, it shall not have a major burden on the team working on ORM6 as that's our most important project. I hope we agree on these points? So I think I will spend some time exploring the fesability of a JPA 3.0 in some 5.x branch, while aiming at maintaining backwards compatibility. To address requirement 1# , I'll just explore this without making a commitment to the plan.. also I think it would be interesting to explore a partial migration, for example I suppose it might be possible for us to "accept" the use of mapping annotations from JPA 3.0 (on top of the ones from JPA 2.0) while not exposing the full proper API yet. Considering the API is literally the same contract, if you except the package name, it might be feasible to expose the full JPA 3.0 in a backwards compatible way as well but this might require: - use of bridge methods, e.g. bytecode manipulation at build time [1] - depend on both JPA API packages In particular I wonder, how would you all feel if (for example) Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API artifacts? And additional change to take into account is that the JPA3 API now defines a module-info resource; it would be nice to try taking advantage of that but it's of course more complicated if we have a hybrid JPA 2/3 implementation. I guess that aspect will have to wait for ORM6, but also that ORM6 being rebased on this work could benefit from using the JPA3 groundwork. Thanks, Sanne 1 - https://github.com/dmlloyd/bridger