As per GROOVY-8722, we currently ignore, i.e. throw away, the final modifier for any methods in a trait. We don't claim to support it but we don't indicate in the doco that we ignore it either.
In normal Java inheritance such a method would typically be in a base class. Java doesn't allow final default methods in interfaces. Such a method isn't typically useful for the "api evolution" use case that Java default methods were striving for. The way we implement it, the method gets woven into the class but the final modifier is dropped. 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 in a class implementing a trait with that final method? And if so, must it also be private. What about final methods with the same 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 whichever method wins for inclusion in the class determines what the modifier should be. I am leaning towards (2) which is closest to current behavior but keeps the modifier. Obviously we should document this. Cheers, Paul.
