jakarta.persistence

[gavinking]

For Hibernate 6 we need to decide how we're going to support the jakarta.persistence APIs.

Currently Session directly extends javax.persistence.EntityManager. This means that there's currently no way to use Hibernate without a dependence on javax.persistence.

But eventually we'll need to also support jakarta.persistence. We need to figure out how to do that, and I would rather make sure our strategy is clear before releasing H6.

[Sanne]

We'll want to publish both jakarta. and javax. compatible artifacts for a while [1].

By automating this at build-tool level, it would be easier for end users as they'll be able to switch API at a time which suits them, without having to switch ORM implementation at the same time (which in an ideal world is flawless but in practice could be problematic).

I suggest we start prototyping this in the master (5.5) branch: this branch is unreleased precisely as the "theme" of this minor was meant to be Jakarta. So we could have a couple Beta's in the 5.5 series to polish this and assuming most code changes will be in the build scripts, it should be straight forward to apply on the 6 branch.

1 - and I'd rather have us prepared for a very fluid definition of "while" - as you mentioned in another context, and I completely agree, we will have people wanting to migrate not only this summer but also for some years to come.

[gavinking]

By automating this at build-tool level,

Oh gawd I hate that idea.

It only works for as long as there is no difference between java.persistence and jakarta.persistence: that is, it just kicks the can down the road.

I think we should support both APIs at the same time, via wrappers.

[sebersole]

BTW the (alleged?) problem with having both wrappers is that IDE's will auto-suggest e.g. annotations to autocomplete the package from both APIs, as they will have both on classpath.

Doesn't this depend on how it's structured? For example, if you did composition wrappers then doesn't that mean you can have entitymanager-jakarta and entitymanager-javax and then you just import the right GAV to get the right dependency set?

You can, and in fact this is how we initially had so that we could limit the dependency on JPA. There are difficulties in the wrapper approach though and especially when splitting them out into separate modules.

[Sanne]

BTW the (alleged?) problem with having both wrappers is that IDE's will auto-suggest e.g. annotations to autocomplete the package from both APIs, as they will have both on classpath.

Doesn't this depend on how it's structured? For example, if you did composition wrappers then doesn't that mean you can have entitymanager-jakarta and entitymanager-javax and then you just import the right GAV to get the right dependency set?

Sure that could work. Except, like @sebersole pointed out, it would be a huge mess for us to extract such components. Integration is really tied ATM, and for good reasons.

What do you think of using Java modules? We could have our library link to both and yet not expose them to user's classpath.

[n1hility]

It's a clever idea. I think the issue is then you are forcing a conversion of everything to JPMS, which is arguably more invasive than a simple source conversion switch to jakarta. There is probably still some funkiness in the IDE. If you do a class search for example (say command N on IDEA, you probably still pick up the dups, and possibly set breakpoints in the wrong places etc). There is the added issue that you are forcing the download of duplicate API artifacts that have to be loaded (when running on a JVM). Maybe this amounts to a trivial overhead, but at the end of the day you are forcing the user to pull in elements they don't actually want, when it never makes sense to use both. The approach also seems a little bit more susceptible to issues compared to the other options. For example, if you have a slight ABI difference:

• Build time transformation approach - sortable with a bit of patching logic.
• Wrapper approach - solvable with wrapper logic
• Dynamic transformation - same as build-time, some sort of rules
• Hard fork - N/A

Unless I am missing something it seems to offer no benefit over the other options, but a lot of drawbacks.

[n1hility]

BTW the (alleged?) problem with having both wrappers is that IDE's will auto-suggest e.g. annotations to autocomplete the package from both APIs, as they will have both on classpath.

Doesn't this depend on how it's structured? For example, if you did composition wrappers then doesn't that mean you can have entitymanager-jakarta and entitymanager-javax and then you just import the right GAV to get the right dependency set?

Sure that could work. Except, like @sebersole pointed out, it would be a huge mess for us to extract such components. Integration is really tied ATM, and for good reasons.

(Sorry I thought I must have lost my reply on this one).

Yeah I can appreciate wanting to avoid the added complexity and the difficulty in ensuring hotspot callsites remain monomorphic. Whats particular tricky about investing in any complex solution is the incentive for developers to move to Jakarta is pretty low atm, since there is no new features to move to. This is why I think the options which negatively impact usability aren't a great solution either since. from the users perspective, it's just all pain, and they don't get much out of it.

(Although granted I realize we aren't necessarily talking short term with some of these. I am not actually trying to advocate for a particular implementation approach, more just discussing pros/cons. You guys know best there on how you want to do it. I do care more about the contact from a Quarkus consumption perspective)

[KrishnaST]

Just an opinion.
Its not only about jakarta.persistence. If you guys want to support jakarta.persistence I suggest you completely dump javax.*. for example in one of my projects I am using Jersey 3.0.1 which has dependency on jakarta.xml.bind, in the same project I am using hibernate 5.4.30.Final which has dependency on javax.xml.bind. I have to add two sets of JAXB implementations in my project. same goes for other dependencies which are now fall under jakarta such as jakarta.activation.

the best scenario is you dump javax.* in future final release and directly support jakarta.persistence without wrappers. those who want to stick to javax.* can use hibernate 5.x version.

[beikov]

With Hibernate 5.5.0.Final we now have -jakarta artifacts that are created through build-time transformations. Also see https://in.relation.to/2021/06/04/hibernate-is-jakarta-jpa-2/