Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

Hi Christian, On Tue, 10 Mar 2020 at 11:33, Christian Beikov <christian.beikov(a)gmail.com&gt; wrote: > Hey, > > do you think it is feasible to create a separate artifact that is a > bytecode rewriting of the main artifact, replacing javax.persistence by > jakarta.persistence. This should be no big deal as e.g. the Maven Shade > Plugin does that as well. We would only need to accept additonal > poperties like e.g. jakarta.persistence.jdbc.user in addition to > javax.persistence.jdbc.user. yes that's an option, but beyond the configuration properties (and thanks for reminding me of those!) I think the bulk of our work would be in making sure we recognize both sets of annotations. So for at least annotations and properties, changes would need to be made to the core. Then to expose the different APIs we could have a different, bytecode enhanced artifact, but it gets a bit tricky then for other projects that integrate with it: will all project e.g. Hibernate Search and Hibernate Validator need the same split, and will this lead to an explosion of possible permutations? From my side I think that even if that's cool, it will be hard for people to migrate if your libraries operate on an assumption of "either or": if we could support both mapping styles while exposing both APIs, the migration path becomes easier as people can do it in smaller steps. > That way, only minimal changes would be required and we'd have a > separate artifact that can be consumed for Jakarta EE users. Maybe we > could make Hibernate 6 JPA 3 only? Yes I hope so. A consequence however would be that if we don't do a 5.x version which is able to allow people to use either JPA2 and 3, I would be afraid that we'd be introducing a significant adoption barrier for 6: we need to make sure it's easy for people to get there before we drop JPA 2. Thanks! Sanne > Regards, > > Christian > > Am 10.03.2020 um 12:17 schrieb Sanne Grinovero: >> 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: >> to >> 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 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >