I have created a PR for this: https://github.com/apache/groovy/pull/780
On Sat, Aug 4, 2018 at 8:08 AM Paul King <[email protected]> wrote: > 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. > >
