Hi Walter, I explicitly said we could not remove in 10. 9 will release within the month. All of our removal policies have always been: set the new feature as default in a major release, then remove the old feature in the next. This means you need at least 2 major releases before we can purge the code. I'm willing to entertain setting it as the default in 10, but I am -1 against removing it until we're stable. 1 major release is not stable if we're rewriting the way it works.
-James On Thu, Oct 22, 2026 at 2:00 PM Walter Duque de Estrada <[email protected]> wrote: > Thanks for the feedback > > H5 removal is targeted for G10, that should be plenty of time to find all > bugs in H7 > > > This is the size of the native domain binding branches > > > ┌────────┬───────────────────────────────────────────────────────────────┬───────┬──────────────────┐ > │ PR │ What it does │ > Files │ Lines │ > > ├────────┼───────────────────────────────────────────────────────────────┼───────┼──────────────────┤ > │ #16568 │ native domain binding through Hibernate's annotations │ > 154 │ +37,585 / −290 │ > > ├────────┼───────────────────────────────────────────────────────────────┼───────┼──────────────────┤ > │ #16569 │ make native binding the default, deprecate the classic binder │ > 28 │ +462 / −145 │ > > ├────────┼───────────────────────────────────────────────────────────────┼───────┼──────────────────┤ > │ #16570 │ delete the classic domain binder │ > 269 │ +4,035 / −20,615 │ > > └────────┴───────────────────────────────────────────────────────────────┴───────┴──────────────────┘ > > Thanks > > Walter > > > > On Oct 22, 2026, at 11:47 AM, James Daugherty via dev < > [email protected]> wrote: > > > > 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 > >>> > >>> > >> > >
