[hibernate-dev] Jakarta EE: JPA 3.0 is coming
Yoann Rodiere
yoann at hibernate.org
Tue Mar 10 09:47:59 EDT 2020
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 at hibernate.org
On Tue, 10 Mar 2020 at 14:36, Christian Beikov <christian.beikov at 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/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
> >>
> _______________________________________________
> 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