As per GROOVY-8722, we currently ignore, i.e. throw away, thefinal modifier for any methods in a trait. We don't claim to supportit but we don't indicate in the doco that we ignore it either.In normal Java inheritance such a method would typically be ina base class. Java doesn't allow final default methods in interfaces.Such a method isn't typically useful for the "api evolution" use casethat Java default methods were striving for. The way we implementit, the method gets woven into the class but the final modifier isdropped. We can easily fix the trait mechanics to keep that modifier.But the question is what to do/allow in various edge cases.In particular, should we allow a final method to be provided ina class implementing a trait with that final method? And if so,must it also be private. What about final methods with thesame signature from other traits?I think there are two behaviors which make the most sense:(1) throw a compilation error if non-final and final methods are mixed.(2) allow the current rules exactly as they are now and whichevermethod wins for inclusion in the class determines what the modifiershould be.I am leaning towards (2) which is closest to current behavior butkeeps the modifier. Obviously we should document this.Cheers, Paul.