final is useful documentation to humans that you never plan to change something, and it allows the compiler to do some smallish optimizations. It's also necessary if you want to reference a local variable from an inner class, but that's probably not for the beginner forum. I don't see many people use it heavily. Maybe we should get more used to it.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I was literally about to post a similiar question. As I have to mark certain variables final for useage inside an inner class and wanted to know if there were any side effects of doing such that I should know.
Final more or less describes the variable saying this variable will always reference this object? but in the previously mentioned hashmap you can update the map adding k,v pairs still right?
But in the case of a primitive (say an int), your stuck with the value you put in it yes?
If you used an Integer object instead would you be able to change the value its holding? Something seems wierd about that.
Is the final requirment on variable names referenced in classes their for a particular reason? The only thing I can think is that new object needs to know where to reference the variable... and assigning new objects the variable moves its location in memory, or am I way offbase?
Your understanding about what "final" does is correct, except for your conjecture about Integer -- because Integer is immutable: there's no way to change the int value one represents, final variable or not.
The "final" is required for anonymous inner class access to maintain the illusion that the anonymous inner class is actually using the local variables. It's not -- the locals are copied into the anonymous object when it is constructed and stored in member variables added by the compiler. If the locals could be changed, then the illusion that the anonymous class was using the locals would then be shattered: you would see that any changes to the locals were not reflected in the anonymous class instance.
It's necessary to do this because the anonymous object may (and usually does) continue to live after the method creating it returns. The stack where the locals live is thus often gone before the anonymous object would even look for them -- so it needs its own copies.