0

I read that declaring a method as final leads to performance enhancement. So, doesn't it make sense to declare methods that are not expected to be overridden as final? My question is specifically about the improvement in performance and any associated cons of such usage.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
Rachit Ajitsaria
  • 13
  • 8
  • Related : http://stackoverflow.com/questions/5547663/java-final-method-what-does-it-promise – Aaron Feb 24 '17 at 13:58
  • 1
    Possible duplicate of [Java \`final\` method: what does it promise?](http://stackoverflow.com/questions/5547663/java-final-method-what-does-it-promise) – siddhartha jain Feb 24 '17 at 14:00
  • I read that question and the answers. Some of them allude that the final declaration might help in increasing performance, but do not encourage (or discourage) its use, unless your goal is to specifically stop overriding. I want to know why is this not considered standard practice. Are performance gains too small to merit, or there are a few attached cons. – Rachit Ajitsaria Feb 24 '17 at 14:02
  • 2
    "methods that are not expected to be overridden " - do you just not _expect_ them to be overridden or don't you _want_ them to be overridden? If the latter then use `final`, if the former then think about how many expectations were proven wrong in the long run, then decide for yourself (and as others already stated: performance reasons alone might be invalid or at least have negligible impact) – Thomas Feb 24 '17 at 14:07
  • I was talking about _expected_. But, the other answers have convinced me that there is negligible performance gain. – Rachit Ajitsaria Feb 24 '17 at 14:38
  • You don't write APIs based on what you expect people to do, you set people's expectations of an API based on what you write. Do you _intend_ a method to be overridden? Don't make it `final`, but do write it for heritability. Do you _intend_ a method not to be overridden? Make it `final`. – Lew Bloch Feb 24 '17 at 18:23

2 Answers2

2

I read that declaring a method as final leads to performance enhancement.

That is incorrect for recent HotSpot JIT compilers. My understanding is that the JIT compiler looks at all currently loaded classes to determine whether there is any overriding for each method that it compiles. If none is found, then the JIT compiler treats the method as if it was final1.

So, declaring methods final as an optimization does not make sense.

(This may not apply to all Java platforms; e.g. non-HotSpot platforms with a primitive JIT compiler.)

A better use of final on a method is when you want / need to forbid certain kinds of extension of your classes by subclassing. Whether / when to do this is a matter of opinion. I certainly wouldn't do this "as a matter of course".

1 - A HotSpot JIT compiler will even recompile previously compiled classes if dynamic loading introduces a new subclass that overloads a method that was previously not overridden.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Using 'final' might save time by not forcing the compiler to look through all classes. Will this help the performance? – Rachit Ajitsaria Feb 24 '17 at 14:08
  • The saving would be miniscule. Not something that was worth oprimizing for. And you have to consider the harm of declaring methods `final` when there is no real need to. It can make code reuse harder. – Stephen C Feb 24 '17 at 14:11
  • More harmful is writing methods that aren't `final` without care and planning. _Effective Java_, Josh Bloch: Item 17: Design and document for inheritance or else prohibit it. – Lew Bloch Feb 24 '17 at 18:26
  • @LewBloch - *"Whether / when to do this is a matter of opinion"* - Stephen C, StackOverflow, 2017 :-) – Stephen C Feb 25 '17 at 02:07
  • It's a matter of design, not opinion. Author's choice for sure. It's about what the author intends for the class. – Lew Bloch Feb 25 '17 at 16:27
0

So, doesn't it make sense to declare methods that are not expected to be overridden as final?

I don't believe so. The final keyword is saying that this method can't be overridden (for security reasons for example), not that the original developer doesn't expect that you'd want to override it. That would be very presumptuous and definitely reduce the extensibility of APIs.

As mentioned in the other answer, I wouldn't expect it to make any difference to performance and if it did, you wouldn't notice!

StuPointerException
  • 7,117
  • 5
  • 29
  • 54
  • "Reducing the extensibility of APIs" is, more often than not, the right thing to do, and certainly not "presumptuous", just good engineering. – Lew Bloch Feb 24 '17 at 18:28
  • We're going to have to agree to disagree on this one I'm afraid. In my view, being able to override methods is one of the most useful and core principles of OO design. I've yet to come across a scenario where this has caused problems. If it does, then 'final' is the solution. – StuPointerException Feb 24 '17 at 22:30
  • Just because a language supports inheritance doesn't mean that inheritance is always the right thing. _Effective Java_ says, "Prefer composition over inheritance". Likewise, methods should not always be overridable. Nowhere did I say that being able to override methods is bad. It remains true that more often than not, it's not the correct decision to make a method overridable. You should only make a method overridable when it makes sense, and you can commit to the responsibility of heritability. – Lew Bloch Feb 25 '17 at 00:45
  • Effective Java does say that, however I don't agree with everything I read. I agree, inheritance is not always the *best* solution but if you design an API on the approach mentioned in the original question then you're declaring that heritence is *never* the right solution. – StuPointerException Feb 25 '17 at 01:14