In a response to Cees' post, this guy has the opposite viewpoint on "final":

One thing that made me go ‘whhueungh?!?’ is the conclusion that ‘final’ is a big mistake. I thoroughly don’t get this. Personal experience and generally accepted wisdom both agree that as a rule extending classes is a bad idea unless a class was designed for it in the first place. In fact, I litter ‘final’ statements all over the place. It mostly marks a class as: Don’t try and extend this! Just wrap it - to any developers that come after me. This works out fine. Where there is a generic element to extract (e.g. The functionality conveyed by java.util.Collection and java.util.Set where a HashSet is concerned) there’s usually an interface which gives you the option of wrapping. I wonder which classes he’s so bent on extending.

This assumes that any class is ever "done". I'd argue that such a beast simply doesn't exist, and that - as developers - we have absolutely no idea how the next guy down the pike who has to look atc our code is going to use it. We can guess, we can make assumptions - but that's about it. "Final" simply bakes in our assumptions, and gives that next guy the middle finger. Not with the intention of flipping him off, no - but flipping him off nevertheless.