When should play! migrate to jakarta-jpa?

[aleksandy]

JPA 3.0 don't have backward compatibility with 1.x-2.x versions because of renaming of all packages. As possible solution I see extracting play.db.jpa package in independent module and make two versions of its: jpa 2.2 and jpa 3.0.

But in my opinion maintaining both versions is too complicated and costly.

[tomparle]

It seems that JPA 3 does not bring any new features, and only change packages for legal issues.
I agree that maintaining two versions would be costly, but what would even be the benefits of migrating to 3.0 ?

[aleksandy]

Hi, @tomparle. I believe this is necessary at least to be able to update hibernate up to the next major release.

[tomparle]

Thank you, this is indeed a sufficient reason to migrate.
The migration does not seem very complicated, would you like to propose a PR for this ?

[aleksandy]

Yep, I'll send it soon.

[cies]

Over at RePlay @asolntsev just upgraded Hibernate to 5.6.12Final which exposes jakarta.validation.* instead of javax.validation.*.

Easy enough to fix, but Hibernate already started the move to jakarta for us (in a minor version).

[xabolcs]

JPA 3.0 don't have backward compatibility with 1.x-2.x versions because of renaming of all packages. As possible solution I see extracting play.db.jpa package in independent module and make two versions of its: jpa 2.2 and jpa 3.0.

That would be the best!

But in my opinion maintaining both versions is too complicated and costly.

It is, but it easy to let it rot. 🤷
So just let the contributors do their contributions to keep JPA 2.0 or JPA 3.0 versions alive.
Play! 2 Framework did the same: they shrink the framework by extracting a lot of functionality to it's own module ... and the community have to maintain them.

---

Same goes for play.server.ServletWrapper: it uses javax.servlet.*
It should be extracted it's own module and / or do it's move to jakarta.servlet when the other modules do.