I found a nice article about the use of the final keyword in java at IBM Developerworks.

Declaring methods or classes as final in the early stages of a project for performance reasons is a bad idea for several reasons. First, early stage design is the wrong time to think about cycle-counting performance optimizations, especially when such decisions can constrain your design the way using final can. Second, the performance benefit gained by declaring a method or class as final is usually zero. And declaring complicated, stateful classes as final discourages object-oriented design and leads to bloated, kitchen-sink classes because they cannot be easily refactored into smaller, more coherent classes.

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.

didn’t know that. Guess I will declare less methods final. But I think the author is too negative and that final can have a place in object-oriented design. I use final methods often to enforce a certain behaviour, e.g. to make sure one of my Nodes can only be initialized once I use this init method:

private boolean init = false;
public final void init(...) throws NodeException {
  if (init) {
    log.warn("Already initialized! Call to init was ignored.");
    return;
  }
  basicSetup(...);

  try {
    doInit(...);
  } catch (Throwable e) {
    fail("exception in doInit", e);
  }
  init = true;
}

Sure, I could leave out the final but I couldn’t imagine a scenario where I would want to extend the init in a way I couldn’t do in doInit. And by using final I made sure that an unnamed colleague couldn’t screw up too badly.

If you must use final classes or methods, document why
In any event, when you do choose to declare a method or class final, document the reasons why. Otherwise, future maintainers will likely be confused about whether there was a good reason (since there often isn’t) and will be constrained by your decision without the benefit of your motivation.

Another valid point. And I have to plead guilty to not having done this so far. I’ll try to remember this (and write some docu right now ;-)).

The rest of the article confirms my thoughts about the use of final fields, at least I was doing the sensible thing here…

some final words from JoS

The final modifier is not about performance enhancement, but about stronger typing and cleaner, clearer code.

You should keep your code in good state at all times, with the correct typing in all scopes.
Dino
Thursday, January 13, 2005