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.bei...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev