6:17 a.m.
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:
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
6:29 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:56 a.m.
Hi Christian,
On Tue, 10 Mar 2020 at 11:33, Christian Beikov
<christian.beikov(a)gmail.com> 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
8:34 a.m.
Hey,
I guess it should be doable to have a dependency on and implement both
APIs but I'm afraid you can't do that with plain Java, you need a build
tool to introduce these bridge methods with possible conversions.
I have been using the following tool in the past to support multiple
versions of Spring:
<dependency>
<groupId>com.infradna.tool</groupId>
<artifactId>bridge-method-annotation</artifactId>
<version>${version.bridge-injector}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>org.jenkins-ci</groupId>
<artifactId>annotation-indexer</artifactId>
</exclusion>
</exclusions>
</dependency>
You have to annotate the methods for which to generate bridges and
specify how to convert the return type via a private method.
@WithBridgeMethods(value = javax.persistence.Query.class, adapterMethod
= "convert")
jakarta.persistence.Query createQuery(String queryString) { ... }
If you omit "adapterMethod", it will just do a cast.
There is a maven plugin to do the byte code rewrite during build:
<plugin>
<groupId>com.infradna.tool</groupId>
<artifactId>bridge-method-injector</artifactId>
<version>${version.bridge-injector}</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
</execution>
</executions>
<dependencies>
<!-- Replace the old ASM version by the new one to
support JDK9+ -->
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-debug-all</artifactId>
<version>CUSTOM</version>
</dependency>
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
<version>${version.bridge-injector-asm}</version>
</dependency>
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-commons</artifactId>
<version>${version.bridge-injector-asm}</version>
</dependency>
</dependencies>
</plugin>
But updating ASM for the plugin requires some trickery. Since we are
using Gradle, we have to implement this ourselves anyway and it looks
pretty straightforward:
https://github.com/infradna/bridge-method-injector/blob/master/injector/s...
Overall, this looks doable, but will be a lot of work :D
Christian
Am 10.03.2020 um 12:56 schrieb Sanne Grinovero:
Hi Christian,
On Tue, 10 Mar 2020 at 11:33, Christian Beikov
<christian.beikov(a)gmail.com> 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
>
8:47 a.m.
Hello,
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:
- It feels there's a high chance we'll waste our time on something
nobody needs. Who in their right mind would use both javax.persistence and
jakarta.persistence in the same classloader?
- Very obviously, Jarkarta itself chose to break backward compatibility
by changing the package names. New interfaces don't extend the old ones, as
they theoretically could have since Java EE has traditionally preserved
backward compatibility. There may be legal reasons for that, reasons that
apply to implementations as well?
- JPA 3 spec writers may "plan" not to change much, but as we've seen,
they already have with the module-info.class. Feature creep in JPA 3.0 may
force us to break backward compatibility (e.g. by introducing a method in
EntityManager that conflicts with a method we have in Session), and then
we'll be in a bad situation if we need to implement this in ORM 5.
- Even if we manage to do this easily and with the blessing of Oracle's
lawyers, there's still the question of testing it. Tests will have to be
copied and migrated to the new APIs, and that will be at least as much work
as migrating the main code. It will also impose a significant maintenance
burden each time we add new tests.
I think *if* we want a version compatible with both Java EE and Jakarta,
our only option is to automate this. Configuration properties and XML files
may not be easily migrated automatically, so if we don't automate this
fully, at least to a large extent.
Now, if we were to just create a new major version of ORM for JPA 3...
things might get easier.
We would just need a bit of gymnastics regarding version numbers:
- Rename ORM 6 to ORM 8
- Create ORM 7, based on ORM 5
- Migrate ORM 7 from JPA 2 to JPA 3 (Jakarta)
- Rebase ORM 8 on ORM 7
- Never, ever release an ORM 6.0.0.Final
- Do the same for other projects (Validator is already on this path,
except we released 6 some time ago).
The confusion this may create on the community side will be minimal, but
still... annoying. I know what I'm talking about since I've advertised
Search 6 all over the place, and all these references to Search 6 on the
internet (forums, stackoverflow, blog posts) will only lead to users asking
themselves "where did version 6 go?".
But I think it's an option that requires less work, and the only work it
requires consists of things we'll have to do eventually anyway.
There is, however, the question of how long we'll have to support ORM 5...
and I suspect the answer is "for a long time". Which means the new ORM 7
will need to have everything backported to 5 for a long time. Which means
the maintenance burden in this scenario would probably be similar to
supporting both APIs in ORM 5... I guess
Yoann Rodière
Hibernate Team
yoann(a)hibernate.org
On Tue, 10 Mar 2020 at 14:36, Christian Beikov <christian.beikov(a)gmail.com>
wrote:
Hey,
I guess it should be doable to have a dependency on and implement both
APIs but I'm afraid you can't do that with plain Java, you need a build
tool to introduce these bridge methods with possible conversions.
I have been using the following tool in the past to support multiple
versions of Spring:
<dependency>
<groupId>com.infradna.tool</groupId>
<artifactId>bridge-method-annotation</artifactId>
<version>${version.bridge-injector}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>org.jenkins-ci</groupId>
<artifactId>annotation-indexer</artifactId>
</exclusion>
</exclusions>
</dependency>
You have to annotate the methods for which to generate bridges and
specify how to convert the return type via a private method.
@WithBridgeMethods(value = javax.persistence.Query.class, adapterMethod
= "convert")
jakarta.persistence.Query createQuery(String queryString) { ... }
If you omit "adapterMethod", it will just do a cast.
There is a maven plugin to do the byte code rewrite during build:
<plugin>
<groupId>com.infradna.tool</groupId>
<artifactId>bridge-method-injector</artifactId>
<version>${version.bridge-injector}</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
</execution>
</executions>
<dependencies>
<!-- Replace the old ASM version by the new one to
support JDK9+ -->
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-debug-all</artifactId>
<version>CUSTOM</version>
</dependency>
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
<version>${version.bridge-injector-asm}</version>
</dependency>
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-commons</artifactId>
<version>${version.bridge-injector-asm}</version>
</dependency>
</dependencies>
</plugin>
But updating ASM for the plugin requires some trickery. Since we are
using Gradle, we have to implement this ourselves anyway and it looks
pretty straightforward:
https://github.com/infradna/bridge-method-injector/blob/master/injector/s...
Overall, this looks doable, but will be a lot of work :D
Christian
Am 10.03.2020 um 12:56 schrieb Sanne Grinovero:
> Hi Christian,
>
> On Tue, 10 Mar 2020 at 11:33, Christian Beikov
> <christian.beikov(a)gmail.com> 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
>>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:19 a.m.
Hi,
On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere <yoann(a)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
9:37 a.m.
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(a)gmail.com>
wrote:
Hi,
On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere <yoann(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:12 p.m.
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(a)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(a)gmail.com>
wrote:
> Hi,
>
> On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere <yoann(a)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(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
6:15 p.m.
On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero <sanne(a)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
3:41 a.m.
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.
What's to stop us from supporting JPA2.0 in ORM 7, with the same hacks you
mentioned for JPA3?
- 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 clear about the fact that this is a major version, since we're
switching to different APIs by default and will ultimately remove the old
ones.
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
Hibernate Team
yoann(a)hibernate.org
On Wed, 11 Mar 2020 at 00:17, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero
<sanne(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:17 a.m.
On Wed, 11 Mar 2020 at 12:16, Yoann Rodiere <yoann(a)hibernate.org> 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 hear you: I'll make sure to focus on reading the mapping
(annotations) can be done as an independent PR and POC; not planning
to use any bytecode hacks for that.
I believe the mapping is actually the most important aspect: we can
drop the others, or iterate on such aspects later if we feel like we
need more.
Regarding on ORM7, ORM8 ... I remember talking about such options with
Steve and I believe he was open to it but we both agreed it's a last
resort choice, so let's hope that won't be necessary.
Thanks,
Sanne
What's to stop us from supporting JPA2.0 in ORM 7, with the same hacks you mentioned
for JPA3?
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 clear about the fact that this is a major version, since we're
switching to different APIs by default and will ultimately remove the old ones.
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
Hibernate Team
yoann(a)hibernate.org
On Wed, 11 Mar 2020 at 00:17, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
>
> On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero <sanne(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
1748
days inactive
1749
days old
10 comments
5 participants
participants (5)
-
Christian Beikov -
Guillaume Smet -
Sanne Grinovero -
Steve Ebersole -
Yoann Rodiere