We don’t need Hibernate 6 to release Grails 7

[gsartori]

Hibernate 6 improves performances so it’s worth to consider moving ahead and supporting it. At the moment though we should consider the priority on security issues.

Databases are consolidated technologies, having the latest ORM is something that could wait.

Having the latest web framework cannot.

[jamesfredley]

@gsartori Do you know of a work around for the following?

Spring Boot 3.x switched to the jakarta.persistence package namespace of JakartaEE 9+, which is supported in Hibernate 6.

Spring Boot 2.x uses the javax.persistence package namespace of JakartaEE 8 and earlier (JPA 2.2 and earlier) used in Hibernate 5.X.

[gsartori]

I have no idea, if it’s just a package name change (meaning the API is the same or compatible) can’t we just fork Hibernate 5 renaming the packages? Better would be creating a “-JAKARTA” version so to not have two separate codebase.

[ppazos]

Is Hibernate 6 a blocker to work on the next release of Grails?

[gsartori]

I don’t think is blocking, it’s just a lot of work and for my understanding it will not be compatible with the applications already written in Grails 6 since the API has changed and GORM relies on that part of the API.

I am no expert though so let’s see if anyone more involved in GORM can give us their opinion.

[gsartori]

Does anybody know if updating GORM 8 to Groovy 4 and Java 17/21 would be possible staying with Hibernate 5 without adopting Hibernate 6?

[rainboyan]

Hibernate started to support JPA 3.0 in version 5.5. All Hibernate artifacts that support the new JPA 3.0 APIs have the suffix “-jakarta” in their name.

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core-jakarta</artifactId>
    <version>5.5.0.Final</version>
</dependency>

https://in.relation.to/2021/06/04/hibernate-is-jakarta-jpa-2/

https://in.relation.to/2021/06/02/hibernate-orm-550-final-release/

[gsartori]

So that means we can go with it right? Am I the only one that is not in a hurry of implementing a new GORM based on a new Hibernate API? We are not 300 people, we need to prioritize and decide carefully where to put our effort on.

[basejump]

5.6.15 I think should be the initial version of hibernate to chase. Its the latest and we are using it fine with GORM 7 and 8 ( v8 as far as I know)
as @rainboyan mentioned add the -jakarta suffix for JPA 3.
see https://central.sonatype.com/search?q=g%3Aorg.hibernate%20v%3A5.6.15.Final&sort=name

[gavinking]

Hibernate 6 improves performances so it’s worth to consider moving ahead and supporting it.

I think this really undersells the deep and fundamental advantages that 6/7 offer over 5. Hibernate 6 involved a huge amount of careful rethinking and re-engineering. There's almost no subsystem of the whole sprawling codebase which isn't now more robust and more powerful. The reimplementation of HQL is alone enough reason to upgrade.

[gavinking]

Yep, if we can have Spring Boot 3 + Hibernate 5 for Grails 7 the next major release implementing Hibernate 6 would be Grails 8 :)

Okay, I mean, I have no particular investment in this, but I hope you fully understand that Hibernate 5.6 is already in limited maintenance mode, and the implications of that:

• The last point release of 5.6 was in February 2023, and it's perfectly likely that that was the very last release of 5.6.
• There will never be a Hibernate 5.7.

[gavinking]

In Grails I don't think any persistence feature goes directly to Hibernate without passing through some GORM component.

I mean, even just a quick scan of the GORM documentation shows me that GORM lets you:

• execute native HQL
• configure things like the second-level cache using Hibernate-defined properties and implementation classes
• use (deprecated) Hibernate-defined id generators

etc.

All this sort of stuff is subject to potential disruption when upgrading H5 -> H6.

How did you use Grails without using GORM?

I have never used Grails.

[gsartori]

I hope you fully understand that Hibernate 5.6 is already in [limited maintenance mode]

Yes, and we need to give priorities. Upgrading a consolidated DB API is not a priority. Relational databases are mature technologies that won't be impacted by an API that we used for years and reached it's maintenance release. Security, on the other hand, is a priority.

When I say the word "priority" you have to think at a CTO deciding what technologies to invest on. And a performance optimization is a good thing, but it is never a priority. It can wait a couple of Grails releases.

[gavinking]

Haha, OK, carry on, as I said, I have no investment in this at all. Just trying to be helpful.

[ppazos]

@gavinking did the HQL language change?

As far as the GORM API doesn't change, I don't see it as a breaking change for Grails, though it could be for the apps created in Grails.

Same for the other two things you mention. I think cache config is GORM DSL.

For the id generators I'm not sure, the only extra generator I used is UUID, and IIRC that is also GORM DSL, not directly hibernate, though there could be other generators.

In general I still think: if the API doesn't change for the developer, then it's not a breaking change, then it doesn't require a major version release if we follow semver. Note this was more a question than a proposal (just to avoid useless discussions).

[jamesfredley]

The latest conversations have been for development to begin around org.hibernate:hibernate-core-jakarta:5.6.15.Final and see how well it will play with Spring Framework 6.1.11 and Spring Boot 3.3.1 within GORM for Grails 7. Whatever functions and is the simplest path is likely what will ship in with Grails 7.

[sdelamo]

I created a task and added to the project board.

[codeconsole]

I think Hibernate 6 should be skipped completely and and the next Hibernate upgrade target should be Hibernate 7.0. I imagine by the time the upgrade is done, 7 will be released. The update can be done independently of grails-core.