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

Gail Badner gbadner at redhat.com
Mon Mar 16 13:37:39 EDT 2020


I'm unsure of the merit of supporting both JPA 2.2 and JPA 3.0 using the
exact same source code and jars.

I have not thought too much about the ramifications of this, but what about
dealing with this by having the gradle build generate JPA 3.0-compatible
source/test code, then changing the release process to test/release both
JPA 2.2-compatible and JPA 3.0-compatible sets of jars, source code, and
documentation?

The JPA 2.2-compatible jars could follow our current naming conventions.
The JPA 3.0-compatible jars could have a suffix like <version>-JPA3.jar.

I believe this would be less work than employing bytecode magic.

Users would have the ability to move to using JPA 3.3 with 5.3/5.4.

Obviously this would have ramifications for WildFly/EAP.

Anyhow, that's my half-baked idea...

Regards,
Gail

On Wed, Mar 11, 2020 at 7:43 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Wed, Mar 11, 2020 at 9:49 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > I'm not a fan of bytecode hacks either, so maybe let's just see what a
> POC
> > looks like before tearing it down?
> >
> >>
> I totally miss why we would want to even work on a POC given how much we
> have on our shoulders? Could someone explain it to me?
>
> IMHO, *if* consumers of our stack want to support both javax and jakarta
> packages, the work will need to be done there i.e. in WildFly or Quarkus.
>
> There's a good chance the solutions will be different given the totally
> different infrastructure of both.
>
> And supporting that for Hibernate ORM only makes sense if the whole stack
> supports that e.g. CDI, HV, Jakarta EL... and AFAICS most of the projects
> will only support either javax or jakarta, not both. So if we want to
> support both, we will need the extra layer I was talking about at a global
> level, not in Hibernate ORM.
>
> I wouldn't open the door at supporting both in ORM and let the consuming
> projects decide of the strategy they want to follow and how they want to
> solve the issue globally.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>


More information about the hibernate-dev mailing list