On Mon, Feb 2, 2009 at 3:37 PM, grauzone <n...@example.net> wrote: > As far as I know, interface methods can still be final methods in a class. > final methods are only disallowed to be overridden further. But it's > perfectly fine to mark a method final, that overrides a method from a super > class. final so to say only works in one direction.
Sure, the method will be final, but it will still be virtual. The way interfaces work is by basically giving you a slice of the vtable. > Then the compiler can optimize calls, if they are statically known to be > final. If not, it still has to do a vtable lookup on a method call, even if > the actually called method is final. The compiler can't optimize calls on interface references away. The function that's using the interface reference only knows as much as the interface tells it. If some class implements the interface and marks its implementation of the interface as final, it doesn't matter, since the method is not marked final in the interface (and can't be!). Okay, so *if* the compiler inlined the call to the function that took the interface reference, *and* it was smart enough to recognize that that interface reference did not escape, *and* it was smart enough to realize that the interface really pointed to a class, *and* it knew that the implementation of the method was final, it could inline it. But that seems like an incredibly smart compiler and an incredibly rare situation. I also don't believe in relying on optimizations that are not enforced, as it makes for nonportable code.
