10

Now, I recently ran into a recommendation that you should use the keyword final as wide as possible. This is good in order to prevent a programmer from shooting his own leg - that is, reassign the variable that should not be reassigned.

But, does it serve any other goal? That is, can JVM use information about the final variables in order to optimize the bytecode somehow, so it would ran faster (build a better pipelining or use it in a multithreaded environment)? Or is just a syntactic sugar that minimizes the possibility of errors during code development?

SPIRiT_1984
  • 2,717
  • 3
  • 29
  • 46
  • final or you can say constant help's in Compiler Optimizations. e.g:- Constant Folding,Constant Propagation –  May 28 '15 at 12:26
  • Related: http://stackoverflow.com/questions/3961881/why-defining-class-as-final-improves-jvm-performance?rq=1 – Patrick May 28 '15 at 12:28
  • "Or is just a syntactic sugar that minimizes the possibility of errors during code development?" Actual intelligent thought minimizes errors. Without that, the final keyword is not only syntactic sugar but a placebo too. – Gimby May 28 '15 at 13:25

4 Answers4

5

As far as variables go, Java is smart enough to figure that a variable is not being changed anywhere in the method, and use this knowledge for optimization purposes. It does not need you to mark a variable final in order to know that.

Methods are a slightly different story: when you mark a method final, Java can invoke such method faster, because it no longer needs to check for its overrides. Still, hotspot is smart enough to figure out that there are no overrides, with or without the use of final.

Generally, though, this recommendation is intended to make your code easier to read and understand by others: making a variable final tells you readers that you are making a constant; making a class final tells your readers that the class is not designed for inheritance; making a method final tells your readers that the logic of that method should stay invariant across the inheritance hierarchy. In the long run, this information is more valuable than the potential to optimize your running code.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • What about private methods? Do they need a final keyword? After all, they definitely cannot be overridden. – SPIRiT_1984 May 28 '15 at 12:25
  • @SPIRiT_1984 `private` methods do not need to be marked `final` - they benefit from the same optimization as final methods (`static` methods get that too, because they cannot be overridden in Java). – Sergey Kalinichenko May 28 '15 at 12:28
  • "Java" (hotspot really) is generally clever enough to figure out if a method is never overwritten and does those optimizations anyhow, so yeah last paragraph. – Voo May 28 '15 at 13:20
5

IBM states:

Like many myths about Java performance, the erroneous belief that declaring classes or methods as final results in better performance is widely held but rarely examined. The argument goes that declaring a method or class as final means that the compiler can inline method calls more aggressively, because it knows that at run time this is definitely the version of the method that's going to be called. But this is simply not true. Just because class X is compiled against final class Y doesn't mean that the same version of class Y will be loaded at run time. So the compiler cannot inline such cross-class method calls safely, final or not. Only if a method is private can the compiler inline it freely, and in that case, the final keyword would be redundant.

MKorsch
  • 3,822
  • 3
  • 16
  • 21
2

I think this recommendation is a bit too unspecific.

For example; I would recommend to avoid using final on classes and methods by default (because final classes break unit tests, respectively force you to use specific unit test frameworks to overcome final methods/classes).

I also find that using final for method parameters is just a waste of "screen space" (and thus: wasting "energy" on the side of the reader).

On the other hand, having only final attributes for classes can turn objects of such classes into immutable thingies; and that is a good thing.

As you see; there are many pros and cons on the usage of final; and I think that "readability" most often wins over "potential" performance improvements.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
1

final methods may or may not be inlined by the JVM until they after they are loaded by the JVM. So, if you're sure the method is not going to be redefined, mark it as final.

Constants should always be static final since they will be immutable and jvm does not need to keep track of these variables since they will never change.

Farhad
  • 388
  • 2
  • 13
  • _if you're sure the method is not going to be redefined, mark it as final._ I would never feel sure of that unless I knew of a reason why the method _must_ not be redefined (e.g., if it is called from a constructor). Just because I can't think of a reason to override a method does not mean that some other programmer won't think of a reason. – Solomon Slow May 28 '15 at 13:51
  • @james-large, generally, when you're building a library and want to control which classes and methods are "allowed" to be overridden, final keyword just gives you a mechanism to do so. That is what I meant by my statement. – Farhad Jun 01 '15 at 06:02
  • 1
    Right, and I would never want to control that unless I knew of a special case where a client override could prevent one of _my_ classes from behaving the way I promised it would behave. – Solomon Slow Jun 01 '15 at 13:16