[hibernate-dev] Jakarta EE: JPA 3.0 is coming
Christian Beikov
christian.beikov at gmail.com
Tue Mar 10 09:34:19 EDT 2020
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/src/main/java/com/infradna/tool/bridge_method_injector/ProcessMojo.java
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 at 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 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
>>
More information about the hibernate-dev
mailing list