I must confess I neither fully understand the issue, nor do I know what to do against the problem from the groovy side. I know only that a synthetic/bridge flag is no solution, since that makes problems in the IDE. I also do not know Hibernate enough to say if setting the annotation on the base class that implements GroovyObject is enough, because the methods you override here are form the GroovyObject interface. And then there is the general mechanism. If I invoke a method on a class C and this class implements GroovyObject, then the first thing, the runtime will do is using getMetaClass to get the meta class for C. For a proxy object that instead extends A but proxies an instance of C to work correctly I actually would need a meta class of A or the proxy class extending A. To get this result we would require the proxy not to proxy getMetaClass.

Groovy has made changes to ensure a method call using reflection is always done using the most general base class possible. That means for toString we would always use Object. for a getMetaClass call we would always use GroovyObject. This means that the situation is different from 2009 and if you get the meta class of C, you can still use it form method calls on the proxy of the C instance that is based on A, as long as you stick to methods from A.

I think for Roger the issue is actually different. I thought that adding @Transient would prevent Hibernate from persisting the meta class. Is this not the case?