playframework / play1

Play framework
https://www.playframework.com/documentation/1.4.x/home
Other
1.58k stars 682 forks source link

Upgrade to Hibernate 5.6 -> 6.x #1484

Open cies opened 6 months ago

cies commented 6 months ago

I could not find an issue for this dependency upgrade yet. It may for good reasons that Play1 targets Hibernate 5.6: I'm very interested in what those reasons are :)

Over at RePlay we have a not too elaborate PR for the 5.6->6.4 bump that passes most the tests.

6.4 supports JDK21, while 5.6 does not (only up to JDK18). By this issue JDK21 support is supposedly added to Play1. It seems that JDK19 support was added before to Play1: in my experience JDK19 should work with Hibernate 5.6, but as said before it is not officially supported.

Please know that Hibernate 5.6 is the oldest release that is in limited support mode as of august'24. This makes me believe it will soon be unsupported.

aleksandy commented 6 months ago

The main obstacle to this update is the loss of backward compatibility. Because hibernate 6+ uses Jakarta Persistence API instead of Java Persistence API.

The ticket depends on #1390

cies commented 5 months ago

The main obstacle to this update is the loss of backward compatibility. Because hibernate 6+ uses Jakarta Persistence API instead of Java Persistence API.

That "upgrade" from java->jakarta was super easy for us. A whole project string replace was all it needed. The in RePlay we did this upgrade on Hibernate 5.6, as there exists hibernate-core-jakarta. In my project we needed this as we also used jOOQ, which bit the bullet and went with the jakarta namespace. Since we wanted to use features in new releases of jOOQ we had to upgrade it which resulted in ugly warnings iirc. Then we pushed for this "upgrade" of Hibernate 5.6 (to 5.6-jakarta) in RePlay. Very painless, and it has to be done at some point somehow.

cies commented 1 month ago

https://github.com/replay-framework/replay/pull/229 the changes that were needed in RePlay for the java->jakarta namespace change. Pretty minimal.

davidcostanzo commented 1 month ago

I'd also like to see this happen for two reasons:

First, there's a Hibernate bug that was introduced when Play was upgraded from 1.6.0 to 1.7.1 (hibernate from hibernate-core-5.4.1.jar to hibernate-core-5.6.5.jar) that caused my Play app to run out of memory. In short, I have a controller action executes some HQL to read many records, processing them one at a time with a ScrollableResults, and periodically clears the persistence cache to require only constant memory. The bug in Hibernate makes this strategy use linear memory because Hibernate leaks some memory. I opened this bug on Hibernate. It has been fixed in Hibernate 6.X but they say it won't be backported to Hibernate 5.X.

Second, now that Play supports Java 17, I want to rewrite my HQL using text blocks. Before I used String concatenation, which made it possible to add inline comment the HQL using Java comments (in between the concatenated lines). In a text block, I can't use Java comments. Hibernate 5.X does not support comments, but Hibernate 6.X does.

I don't know what the cost of upgrading the Play framework itself will be, but the cost to upgrade my applications is small compared to the benefits.

cies commented 4 weeks ago

@davidcostanzo

First, there's a Hibernate bug that was introduced when Play was upgraded from 1.6.0 to 1.7.1 (hibernate from hibernate-core-5.4.1.jar to hibernate-core-5.6.5.jar) that caused my Play app to run out of memory.

We did not run into this.

Second, now that Play supports Java 17, I want to rewrite my HQL using text blocks.

We're on Kotlin now. (RePlay supports Kotlin)

Hibernate 5.X does not support comments, but Hibernate 6.X does.

Cool! Did not know that, but we use jOOQ for all complex queries and new features. The added type-safety is lovely.

I don't know what the cost of upgrading the Play framework itself will be, but the cost to upgrade my applications is small compared to the benefits.

Have a look, we just released a version with Hibernate 6.4 after we tested it thoroughly and is already running in production for some time.

There were some issue while upgrading. We've mentioned it in the porting guide (which is part of the main README).