Link Details

Why the down votes?

"class A, subclass B, and sub-subclass C. It sees a final method in A which it inlines into C. But at runtime, the versions loaded for A and B are different—the method is not final in A and it's overridden in B."

How can a final method in A not be the same method in B and C? I'm confused :)

You might compile a class with one version of a library, where the method was final, but use another version of the library at runtime, where it was not. But I don't think this is common and a library that changes API like that is not backwards compatible anyway (and the client should be recompiled).

thanx, hadn't considered that scenario.

I find the conclusion harmful: "don't use final for methods just for performance reasons".
That is not the main reason why people sue final methods! The main reason is a design choice: we don't want that method overridden!
Now about the situation described, I think it is not likely to encounter it in real life: why would you load a different A class at runtime (I mean without recompiling your whole source code)?

The JIT can inline non final methods. It is even able to 'revert' back if the assumption that a method can be inlined, doesn't hold anymore.

I use finals for making clear that stuff can't/should not change, and it also is a great help for dealing with JMM issues.