Several of us have objected to removing Hibernate 5. Until we have a major release without rewriting critical Hibernate 7 functions or being forced to discontinue Hibernate 5 support due to Spring, I do not believe the Hibernate 7 code line can be considered fully stable. Thus, I'm against removing it.
Concerning the domain binder: simplifying the code sounds great, but I need to better understand the implications before fully endorsing it. 10.0 isn't expected to go live until later in 2027, so we should have plenty of time to work on it. I would just suggest we incrementally make these changes. I personally do not want to review a 3000+ file PR again. I can say with my current commitments, travel, and 8.1/9.0-M1 releases, I don't think I'll have time to look until December. On Wed, Oct 21, 2026 at 1:33 AM Gianluca Sartori <[email protected]> wrote: > That sounds impressive, deleting redundant code is always a good thing. > > On H5, I would not rush removijg it. Security risks are low to zero. When > porting an older app to a newer Grails there is already some work and a lot > of testing to do even keeping H5. > > Can’t we just deprecate it and declare it is a frozen legacy module > somehow? > > With new apps there is no issue moving to the latest Grails + H7. > > I am thinking about some apps we have where the cost of moving and testing > and maybe fixing some issues after the deployment in production is not > justified. > > I don’t know, my feeling is that switching to a new ORM to manage my old > databases is costly with no real value: if the database is working with H5 > today, it will work with H5 for other 10 years, since security is not an > issue and the database is an inner detail that BTW evolves much slower that > the rest. > > The database we are building today are the same we were building in the > late 90s with MS SQL Server. > > The cost for Grails would be to make sure H5 keeps working with the > evolution of the framework, for example the plugin subsystem or other > stuff, but basically make sure the H5 plugin runs. > > Maybe these are just my worries, but that’s my opinion on H5. > > > Gianluca Sartori > -- > https://dueuno.com > > On Wed, 21 Oct 2026 at 03:24, Walter Duque de Estrada via dev < > [email protected]> wrote: > > > Team: > > > > I cant attend the am meetings so I will tell you about 2 major changes > > that I have in Hibernate modules in Grails 10.0.x > > > > Native domain binding in GORM for Hibernate 7: > > > > PR #16568 adds native domain binding to grails-data-hibernate7. Instead > of > > GrailsDomainBinder building Hibernate's boot model by hand (about 5,800 > > lines that re-implement what Hibernate's annotation binder already does), > > GORM now generates a JPA-annotated class for each domain class from its > > evaluated mapping and lets Hibernate's own annotation binder bind it. The > > application's real domain classes remain what Hibernate persists, loads, > > queries and proxies; the generated classes exist only while the mappings > > are bound. > > > > The code lives in one package, > > org.grails.orm.hibernate.cfg.domainbinding.jpa, with the value records in > > the subpackage jpa.facets. > > > > How it is verified. The specs under grails.gorm.tests.generated run the > > same behaviour through both bindings. Two differential specs compare, for > > every scanned test domain class (about 1,170 entities and 3,400 > > properties), what the generator states against what the classic binder > > bound, both at the Hibernate boot-model level and at the DDL level. The > > classic side is frozen as recorded data under > > src/test/resources/classic-oracle, so the comparison survives the removal > > of the classic binder in #16570. The whole core suite also runs through > the > > generated classes. > > > > The same reading order is now in a package-info in the jpa package and in > > the hibernate-developer skill, and in the "Where to start reading" > section > > at the top of the PR description. > > > > Removal of H5: > > > > This was EOLed a long time ago. > > > > Thanks > > > > Walter > > > > >
