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

Tue Mar 10 14:12:13 EDT 2020

I didn't mean to suggest that we fully implement both JPA 3.x and JPA
2.y in any one version.

I'm really just focusing on those principles I mentioned; the main ones being:
 - don't spend ages on this effort
 - don't add pressure on ORM 6
 - not getting in the way of eventual ORM6 adoption

What happens next is definitely very open up for options, but bear in
mind that we might need to have some JPA3 implementation soon, so some
plan needs to be devised. As a broad idea, WildFly would like to have
it by September - that's not fully decided and they are asking us how
reasonable that could be.

In more formal terms, we have the spectrum of certifications:
 - [fact] Hibernate ORM 5.3 passes the JPA 2.2 TCK (as does ORM 5.4)
 - [goal] to have Hibernate ORM 6 (or 7?) to pass the JPA 3.0 TCK &
certification

To be fair what happens in the middle is more like a gray area. I
agree with Steve on wondering about how far we want stuff to be
simultaneously supported: in my opinion it would be totally fine if -
for example - Hibernate ORM 5.5 would materialize as a special edition
which is totally backwards compatible, able to pass the JPA 2.2 TCK,
and perhaps also able to load entities mapped via JPA 3 annotations
while not exposing anything else from Jakarta. As long as we don't aim
at JPA certification we can of course do whatever works for us, so
let's take this as an option.

A second step would be - assuming ORM6 branch incorporates such
changes - to also support both JPA 2.2 and JPA 3.0 annotations in the
ORM6 branch, but completely switch to the JPA 3.0 API and
configuration settings so to keep things simple.

The "big bang" approach that Validator implemented is an option as
well; but the context is a bit different as we're having an actual
major release being developed, and the matter of possible time
pressure.

We know from experience that people tend to linger on the older
versions for too long, so you need both a carrot and a stick to move
on. It would be good to be able to say to people that want JPA3 that
they need to upgrade to 6; and yet it also needs to be relatively easy
to upgrade - and that's where we have a problem: Jakarta haves you
"just search and replace all javax. strings" - but if we incidentally
also ask people to adapt to all changes from ORM5 to 6 - even if they
are small - it muddies the strategy significantly.
Conceptually I'm not sure if JPA3 is going to scare people off or
rather make people interested, as some might want to avoid it as there
is no immediate benefit, while others will need it: surely we'll have
many users in both camps. Yet I'm convinced that having a release
which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
renamed) would be no good to us, as it would create an adoption
barrier for both cathegories of people: the ones not interested to
migrate away from JPA2, and the ones not interested to migrate beyond
JPA3.

Finally, consider the timeline. Both WildFly and Quarkus will need a
JPA 3 implementation soon: we either have it all ready or we need to
be able to deliver at least support for the mapping so that they can
do some bytecode magic to cover the other areas such as API; that's
why I see some merits in having some flexible intermediate support -
POC pending of course.

Thanks,
Sanne

On Tue, 10 Mar 2020 at 14:39, Steve Ebersole <steve at hibernate.org> wrote:
>
> I'm curious... why are we saying that we need to simultaneously support
> both sets of annotations and config settings?
>
> As a user, if I choose to use the Jakarta-based JPA I would fully expect
> that to only work with the Jakarta-based annotations and settings.
>
> Is there something in the spec I am missing that says we need to understand
> both simultaneously?
>
> On Tue, Mar 10, 2020 at 9:21 AM Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
> > Hi,
> >
> > On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere <yoann at hibernate.org> wrote:
> >
> > > > 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?
> > >
> > > Mixed feelings, to be honest
> >
> >
> > Same here. I thought we decided against supporting both at the same time.
> >
> > As for HV, I won't. HV 7 will only support jakarta packages all over the
> > place. And if you want jakarta packages, you will have to use HV 7. And
> > it's going to be a big bang, meaning you also need jakarta-package CDI and
> > so on.
> >
> > That is an important point for ORM too because that means you will have to
> > also support both legacy CDI and new jakarta CDI if you want to support
> > both at the same time. Pretty sure it's going to be a nightmare.
> >
> > Quick feedback on the HV move: it was relatively easy (but it's less
> > code/complex than ORM).
> >
> > >From my point of view, the options are:
> > 1/
> > - release an ORM 5.5 with Jakarta packages but it will break all existing
> > applications in a minor, not ideal
> > - move 6 to jakarta packages too to avoid conflicts
> >
> > 2/
> > - rename 6 to 7 (or 8)
> > - release a 6 (or 7) with jakarta packages
> >
> > I don't think tying the Jakarta package release to the 6 cycle is a good
> > idea so that's not an option for me.
> >
> > Note that in any case, some patches will be significantly harder to
> > backport to 5.4 (and vice versa).
> >
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>