anchor.diff:  
   However, before I go into detail on what my exact position is on the subject, and why nonbelievers are doomed to burn in Mutability Hell, let's recap what, exactly, `final` means when it appears in Java code.
   
  -== Keyword Overload
  +== Keyword overload
   
   First of all, any Java programmer worth his or her salt knows that `final` actually has two completely different meanings in Java, depending on where it is used.
   
  
positive.code: 
  I am primarily concerned with the first meaning of `final` in this article, though I will touch on the second a bit as well.
  
  == `final` Thesis
  
  Now that we have covered the meanings of `final`, we come back to the subject of when it ought to be used.
  
  After experimenting with different styles over the course of several years, I have settled upon the strongly held conviction that *`final` should be applied to _all_ fields, parameters, and variables except for cases where the value definitely needs to change over time* (and only after considering the alternatives). The sole exceptions to this rule are constants defined on interfaces, which are implicitly `final` without needing to use the keyword, and parameters of abstract methods, where `final` has no effect.
  
  == Preemptive Strike
  
  Before I go on to answer the question of "Why?", I will first preemptively counter the reasons I've heard for "Why not?".
  
  
negative.code: 3. If you're concerned about verbose source code, Java is _not_ the language for you. Address all complaints to James Gosling.
  4. Purely cosmetic concerns take a back seat to functional ones.
  
  == On a soapbox
  
  Now that's I've gotten that out of the way, it's time to explain why you should be using `final` wherever you can.
  
  