final
simply means that the reference/primitive variable can not be assigned a new value. It's not the same as const
concept (which Java doesn't have); it does NOT guarantee immutability. String
in Java, of course, is already immutable enough (barring nasty reflection attacks).
Using final
modifier for parameter arguments will have no effect on security or garbage collection. It's done for readability and to enforce coding convention that parameter variables aren't being reused in the method to store other values.
Upon encountering a final
modifier, a human reader can be assured that the value of this variable, once assigned, will not change within its scope. The compiler would enforce this behavior, and would not compile a program that illegally tries to assign a new value to variable that is declared final
.
A variable can be declared final
. A final
variable may only be assigned to once. It is a compile time error if a final
variable is assigned to unless it is definitely unassigned immediately prior to the assignment.
As mentioned, however, final
does not in itself guarantee immutability of the object being referred to. A final StringBuilder sb
declaration guarantees that sb
, once assigned and within its scope, will not refer to another StringBuilder
instance. StringBuilder
itself, of course, is a mutable object.
final
and inner classes
Another use of final
modifier is to allow local variables etc to be used by an inner class:
Any local variable, formal method parameter or exception handler parameter used but not declared in an inner class must be declared final
.
This has to do with how inner classes using these variables are compiled in Java, an implementation detail that perhaps is not all too relevant for the discussion. Essentially, the values of these final
variables are given to the inner classes at construction time. Subsequent changes to the local variables (if allowed) would not be seen by the inner class instance. To ensure proper semantics, these local variables must thus be declared final
.
Effects of final
modifier for local variables at run-time
final
modifier for local variables/formal method parameters is a compile-time concept, and is not present at, say, the bytecode level (i.e. it plays a very different role than final
modifier for fields, classes and methods). Thus, this concept simply doesn't exist at run-time, where final
and non-final
local variables are indistinguishable; the usage of the keyword itself would not have any effect on garbage collectibility and/or performance.
Garbage collectibility is defined in terms of whether or not there are live references to an object. Local variables and method arguments go out of scope at the end of the method (or the block they're declared in), regardless of whether or not they're declared final
. Going out of scope means the reference is "dead". The object itself may still have live references from elsewhere.
In this particular case, the formal method parameters are declared final
so that they can be used in an inner class. As mentioned above, the inner class would copy these references for its own use. Thus, in this particular case, the Authenticator
object would have references to the String
objects referred to by a
and b
.
Simplistically speaking, the more references to an object there are, the harder it would be to qualify as garbage illegible for collection. The underlying factor, however, is the liveness of these references, not whether or not they're final
.
On profiling
It's good to understand the concepts to clear any doubts on memory usage/performance issues; it's better to just profile and see if the issues are real, and fix them as necessary. A well-designed system should be highly adaptable to these kinds of changes.