Why should final'ing be avoided under any cases?
Because java is dynamically-linked, always. Which means that someone can compile against your source, extend a class, and then when they try to run it using your binary it will break.
That's not a great example, but the simplest I can think of off the top of my head
Hence it's bad practice to final things unless you really, really mean it (i.e. there is no way this method could ever be deliberately overridden without causing grave problems - e.g. sun final'd some methods in AWT which allocated or interacted with native memory, which would cause nasty crashes in the JVM if you overrode them. I know because I found some other ways to get at them
Final should be only avoided because it leds to bad code, but if a optimizer does this for you you till get more performance.
As I asked before: what performance difference do you see? My guess is the answer is "none at all". It *used* to be necessary to final methods to get them to become candidates for certain optimizations, e.g. inlining, in the JVM, but this was fixed quite a while ago (3 years ago? 5 years ago?).
I'm sorry that you thought I was trotting out a knee-jerk answer; if you are genuinely seeing performance differences, then that's wonderful. But unless you're doing some funky stuff I very much doubt you are.
In fact it decreases the work the jvm has to do at method-lookup since final tells the jvm that no overridden methods except the actual are there and that no method-class matching needs to be done!
I'm wary of making such statements until I've checked what the current JVM actually does in these situations. For instance, the recent addition of co-variant types and parametric function despatch means this part of any JVM is likely to (have recently been) be re-architected.
Maybe you're right and it's still an issue. Do you *know* this? (I ask out of interest - I haven't had time yet to go trawling to try and find some docs from Sun on what they've done about this in 1.5; the fact that I've spent years looking for similar docs from them about their NIO implementation and still not found any puts me off looking unless someone else finds it first
Another benefit is, that JVM knows at jit-compile-time that no classes may override this method later and not deoptimizing is needed.
Again, are you sure? This is somethign that used to be an issue, but I'm not convinced it matters any more (unless you do something very unusual in your programming)