About local final variables in Java_问答_开发者

In java Program, parameters which is defined as String in method declaration. But in method definition it is accessed as final String variable. Whether it'll lead to some issues (like security, memory problem)?

For Example:

Method Declaration

开发者_StackOverflow社区join(String a,String b);

Method definition

public void join(final String a,final String b)
{
    Authenticator au = new Authenticator(){
        public PasswordAuthentication getPasswordAuthentication(){
        return new PasswordAuthentication(a,b)}
    };
}

Please help for me and clarify my doubts. Thanks in advance

P.S. I'm accessing a and b as final variable because I've got to use it in the inner class.

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.

JLS 14.2.4 final Variables

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:

JLS 8.1.3 Inner Classes and Enclosing Instances

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.

No, the final on an argument only influences the local copy of the argument on the stack frame of the method. It does not in any way influence or change the value passed as an argument.

Making the variables final does not have anything to do with security or memory allocation. It does not have any impact on security or memory use.

Adding final doesn't change the signature or create any other issues. Thus, it is fine to use in a method specified by an interface (for instance). It only makes a difference to code inside the method.