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

[Christian Beikov]

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.

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?

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev