In fact I wish final was the default modifier for all my fields, variables, and parameters. You should have to announce your intention to overwrite an already initialized object reference. After years, I find it is a rarity.
There is nothing worse that digging through a large 500 line function and not being able to see what is changed and where. Even more frustrating when you go to extract a method from said too-large codeblock and cannot do so easily because of the sprawled out variable declarations and initializations and the occasional "I like this variable name so I'll reuse the reference" laziness.
The trouble is it looks so terrible when used properly, which should be almost everywhere! It looks pretty satisfying on fields, but over all parameters and variables it gets to be a little much.
That is why one of my biggest wishes for the Java language is that final be the default and there to be a mutable or similar keyword for the handful of times you need it. It would be an excellent aid to readers of your code, "watch out this thing is going to change." Compilers could even check to see if you have flagged something mutable and aren't actually mutating it. That should be a compile error for variables and parameters, perhaps not for fields though.
Obviously we can't exactly do that ... not so directly.
We have some advantages now we didn't have when Java was created. Annotations. When Java was created there had to be long and deliberate thinking as to what the defaults should be. Everyone would have to live with them and they'd last forever. These days, however, a simple annotation or two on a Java source file could serve as a clean way to change such defaults in an obvious and documented way that can make the code in question far easier to read. It would be syntactic sugar of course and that annotation and the defaults it specifies would compile away just as imports do.
A small bit if sugar with big payoff in ease and readability.
