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

Mon Mar 16 14:28:46 EDT 2020

Personally I'm now leaning to just adopt the "big bang" approach like
Hibernate Validator did, and other specs are doing, as Guillaume
passionately reminded me we have a lot on our plates - and beyond
doing this work we'd need many tricky integration tests.

However as usual we need to keep some open paths, so even though me
might not do any bytecode manipulation let me clarify what I meant by
answering to the questions from Steve:

On Wed, 11 Mar 2020 at 22:54, Steve Ebersole <steve at hibernate.org> wrote:
>
> When y'all talk about the bytecode enhancement solution, I'd like to better understand what you mean exactly.
>
> Do you mean at run-time like we did for ORM when we combined Session/EntityManager?  The problem there is that this only works when we control the environment (WildFly e.g.).  Do you mean at build-time?

I meant build-time, and very limited. Since the new EntityManager API
and the old EntityManager API are exactly the same - except for the
package - it's actually trivial to have the SessionImpl to extend
*both* without needing any adaptors, with one single caveat: those
methods which return an enum, as the types will be defined by the spec
and we won't be able to override those.

But that's exactly the same problem we had when making the SessionImpl
implement both Session and EntityManager; if I remember correctly we
had this problem on a single method and this could be resolved by
using David's bridger tool (to which I linked as [1] in the first
email of this thread).

In terms of dependencies, the ORM core module would need to depend on
both JPA 2.2 and JPA 3.0 API jars.

> Generally I am not a fan of either of these approaches.

Ok, I'm not going to try any of these options for now.

>
> My preference is based on the previous discussions that we intend no more 5.x release families (5.5, 5.6, etc).  Given that I'd prefer that we:
>
> Create a new 5.x family (5.5, 5.9, etc) that adds support for JPA 3 on top of 5.3.  This would effectively "kill" 5.4.  This new 5.x release would be based on the JPA 3 API (renamed packages) and be able to read JPA 3 annotations.  It would be nice if this version could read javax.persistence annotation as well, but to me that is a nice-to-have.  None of us really has the time to tackle that work at the moment.  And who know, maybe a contributor takes that on.

Agreed, and yes my proposal was based on the conversations with you.

I still think it's tempting to see how easily we could read both
families of annotations but we all seem to agree that's just a "nice
to have" that's best deferred.  If someone wants to contribute it, it
might be a bit tricky: it's likely easy to do, but I'm not sure how
far an occasional contributor would be willing to go with integration
tests.

> Convert 6 to use JPA 3 API.  I'd prefer to not support "dual annotation reading" here - based simply on resources.  This is a long term view - moving forward I do not think it is reasonable expectation to use JPA 3 API with JPA 2 annotations.  That might (debatable) make sense for a transitory period, but I'd rather not "waste" the effort here for 6.

Agreed, I didn't mean to suggest we'd do anything different for 6.

Thanks,
Sanne

>
> For (1), in theory, I'd prefer to keep it using the JPA 2 API and read both.  However I suggested using the JPA 3 API there because I assume we are going to need a JPA 3 compliant version sooner rather than later for TCKs.
>
> On Wed, Mar 11, 2020 at 3:51 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On Wed, 11 Mar 2020 at 08:39, Yoann Rodiere <yrodiere at redhat.com> wrote:
>>
>> > > 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.
>> >
>> > I get that, but I'm definitely not as hopeful as you are as to the
>> > reliability of those bytecode hacks you mentioned. But I guess that's an
>> > uphill battle.
>> >
>>
>> I'm not a fan of bytecode hacks either, so maybe let's just see what a POC
>> looks like before tearing it down?
>>
>> What's to stop you from supporting JPA2.0 in ORM 7, with the same hacks you
>> > mentioned for JPA3?
>> >
>>
>> Right, and in fact I mentioned as one of the possibilities for ORM6 to be
>> able to read and interpret the "legacy" annotations from JPA2.
>>
>> I believe that's important to not get in the way of adoption but rather
>> actively help with some flexibility, otherwise people will have a very hard
>> time to upgrade to 6, and that's something that risks becoming a
>> significant burden on us all.
>>
>> Thanks,
>> Sanne
>>
>>
>> >    - People who want JPA3 only have a hack-free ORM 7 that happens to
>> >    support JPA2 annotations.
>> >    - People who want JPA2 can migrate to ORM 7, and we'll provide hacks
>> >    to make it work.
>> >
>> > At least we wouldn't be penalizing people who want to migrate to JPA3 with
>> > potentially unreliable bytecode hacks. Only people who want the latest and
>> > greatest on an older API (which is, after all, quite an unreasonable
>> > request) would have to put up with that.
>> > And we'll be able to completely ignore these hacks in ORM 8 after we
>> > rebased it on 7, since ORM 8 will drop support for JPA2 (I hope?).
>> >
>> > Yoann Rodière
>> >
>> > Sr. Software Engineer, Middleware Engineering, Hibernate team
>> >
>> > Red Hat <https://www.redhat.com>
>> >
>> > <https://www.redhat.com>
>> >
>> >
>> > On Wed, 11 Mar 2020 at 00:17, Guillaume Smet <guillaume.smet at gmail.com>
>> > wrote:
>> >
>> >> On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>
>> >> > 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.
>> >> >
>> >>
>> >> Thus the proposal of Yoann and me to just rename the current 6 to a later
>> >> version and release a new major version that only contains the Jakarta
>> >> package change.
>> >>
>> >> That way, we don't end up doing additional work and having weird versions
>> >> partially supporting both.
>> >>
>> >> --
>> >> 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