The call needs to stem from the "field writer method" generated in org.hibernate.bytecode.enhance.spi.Enhancer#generateFieldWriter. I can see 2 ways...

The first approach would be to directly append bytecode instructions into the "field writer method" CtMethod block. On the one hand, this would be fast. Each "interested party" would need to append its own bytecode instructions into the the "field writer method" CtMethod block.

The second approach would be to use some form of notification bus with listeners. The generated getter and setter methods would send notification that they were called through this bus and listeners could react to that. Here, for example, the listener would essentially be the code you have now to track the field names that have changed. The downside is that this would require multiple method calls, perhaps a list (to hold the listeners), etc.

All-in-all, I think I'd opt for the first approach. It just seems like that will perform better. But stylistically I like the second approach, so I could be convinced on going that way

Also, I wonder if we ought to develop an interface to represent this dirty-checking. The reason being is that we could then allow the user to directly implement the interfaces without the need for bytecode manipulation. We do this for the EntityEntryContext stuff (HHH-7667).

If we did add such an interface, it would also need to be added to the enhanced CtClass definition. That would need to happen in org.hibernate.bytecode.enhance.spi.Enhancer#addInLineDirtyHandling. The methods it adds would be the impls of that interface.

This is similar to the org.hibernate.CustomEntityDirtinessStrategy feature (mentioned in my referenced blog entry), but would be an integral part of the domain model either added by the user directly (implementing the dirty-check interface) or added by us via enhancement.