Any sense in separating mapping annotations from the rest of the API?

[rbygrave]

So given the package change to jakarta.persistence I wonder if this is an opportunity to separate the mapping annotations:

• from the rest of the API as a separate artifact?
• in the same artifact but under a mapping package?

That is part of me wonders if in moving forward it would be useful to separate the mapping annotations such that mapping changes / improvements could be released more easily / frequently? (It might be easier to get agreement on mapping improvements separately from other API improvements?).

Just a thought but given the package change it seems like an opportunity to consider it.

(Maybe this has been discussed in email so I'll go and have a look / search - apologies if it's already been discussed).

Cheers, Rob.

[m-reza-rahman]

I don't think a package move is possible now without breaking backwards compatibility and splitting packages seems rather minor. I suggest just closing this to reduce clutter and be able to focus on higher priority issues?

Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[gavinking]

• from the rest of the API as a separate artifact?
• in the same artifact but under a mapping package?

I think it would be very much worth doing both these things.

It was a huge mistake to have put the mapping annotations in the same package as the APIs, and it's well past time to own up to that mistake and correct it.

[lukasj]

It was a huge mistake to have put the mapping annotations in the same package as the APIs

agree, I've set this up for consideration for the next major version

[gavinking]

agree, I've set this up for consideration for the next major version

Excellent!

[victorwss]

Is the idea to separate the mapping annotations on one side (along with some enums) and the EntityManager, Query and friends, criteria, metamodel and SPI in the other side (possibly also broken down in smaller pieces)? If so, I think that it isn't a good idea and would only create more backward-compatibility and JAR-hell problems for little to no benefits whatsoever.

The migration from javax to jakarta already does great damage and headache to JPA's users, severely breaking the "write once, run everywhere" that allowed people to trust Java. It punishes users and Java developers everywhere preventing, delaying, complicating and/or screwing up software evolution just for the sake of a legalese nitpick problem about naming rights that in fact was created many years ago by Sun and that users and developers should not have to ever care about, but unfortunately have to do. So please, we should not ever again break backward-compatibility without an extremely good reason and I see nothing like that here.

So, what are the real benefits that end users would gain from this separation?

[rbygrave]

what are the real benefits that end users would gain from this separation?

As I see it, the idea is that this would enable other JPA API's to be developed where the mapping is fully reused but the API could be different. For example, perhaps more like Panache or perhaps more along the lines of "Sessionless EntityManager" or maybe something else even.

Panache

With for example something like Panache - https://quarkus.io/guides/hibernate-orm-panache we see the entity mapping annotations reused etc but we don't see EntityManager as exposed API.

"Stateless EntityManager"

I'm extrapolating a LOT on Gavins suggestion here ... but taking the idea of "Stateless EntityManager" in https://github.com/jakartaee/persistence/issues/374 it could be that there could be a "Stateless JPA API" that could be drafted that reuses all the entity mapping but provides a "Stateless EntityManager API" which might be functionally along the lines of Hibernate StatelessSession. Would it be easier for that to develop as a separate API?

Maybe the separation of the mapping annotations would enable a "lightweight" version of JPA to develop which could be argued is more suited for use in "smaller" apps like Lambdas.

Disclosure: I maintain an ORM that uses the JPA mapping annotations but does not use the API (EntityManager etc) so my bias is that I'd prefer the mapping to be separate.