Final Keyword in Method Parameters

final keyword in method parameters

Java always makes a copy of parameters before sending them to methods. This means the final doesn't mean any difference for the calling code. This only means that inside the method the variables can not be reassigned.

Note that if you have a final object, you can still change the attributes of the object. This is because objects in Java really are pointers to objects. And only the pointer is copied (and will be final in your method), not the actual object.

Why Final is used in method parameters

final is used in method parameters to make the references unchangeable after it is passed into the method. This is a specialized way of securing the passed parameters. so, the method receiving will not be able to re-initialize it with new object or value

Does final keyword on method parameter get compiled to bytecode?

TL;DR: You don’t need that information in the bytecode

The final keyword on a parameter means that you cannot assign a value to that parameter inside your method or constructor. It’s the compiler’s job to check that you are not doing this (and the compiler will issue an error message if you do). Once the compiler has done its job, we can be assured that the parameter indeed keeps its initial value throughout. There is no need to have the information in the bytecode that the parameter is declared final. Which is why the information is not there.

From a comment by Link182:

Then how do we know the parameter is final in a compiled library?

You don’t. You don’t need to. What would you use that information for? It’s only relevant for the implementor of the method.

Using final in method parameters in Java

1. Using final modifier on method parameters doesn't make much sense
   since it adds visual clutter to the method declaration without
   buying you much. As far as you can make sure that you don't reassign
   values to those variables, you are good enough to go without final
   modifier on method parameters.
2. Method parameters lie on the stack, and it is local to that
   particular thread as far as that thread doesn't publish it to some
   other thread. Since it is not shared between the other threads, no
   thread safety issue arises here. However, if the current thread
   publishes these arguments, then you are out of luck and the use of
   final modifier doesn't give you any thread safety guarantee.

Here's one such a tasteful use of final modifier to write an immutable class which represents a point in our 2-dimensional space.

class Point2D {
    private final int x;
    private final int y;

    Point2D(int x, int y) {
        this.x = x;
        this.y = y;
    }

    // Remainder omitted for brevity's sake !
}

Once this class instance is created, you can share it freely with other threads and you don't need to bother synchronizing access to it's state. So, immutable objects give you thread safety for free.

You may read JLS § 17.5 for more details on semantics of final fields.

Making java method arguments as final

As a formal method parameter is a local variable, you can access them from inner anonymous classes only if they are declared as final.

This saves you from declaring another local final variable in the method body:

 void m(final int param) {
        new Thread(new Runnable() {
            public void run() {
                System.err.println(param);
            }
        }).start();
    }

Final keyword in method signatures

Java passes arguments to a method by value.

Therefore, no changes to a parameter can propagate back to the caller. It follows that whether or not the parameter is declared final makes absolutely no difference to the caller. As such, it is part of the implementation of the method rather than part of its interface.

What's your motivation for wanting to "obligate sub-classes to use in their methods final variables"?

Why would one mark local variables and method parameters as final in Java?

You should try to do this, whenever it is appropriate. Besides serving to warn you when you "accidentally" try to modify a value, it provides information to the compiler that can lead to better optimization of the class file. This is one of the points in the book, "Hardcore Java" by Robert Simmons, Jr. In fact, the book spends all of its second chapter on the use of final to promote optimizations and prevent logic errors. Static analysis tools such as PMD and the built-in SA of Eclipse flag these sorts of cases for this reason.

Is there any performance reason to declare method parameters final in Java?

The final keyword does not appear in the class file for local variables and parameters, thus it cannot impact the runtime performance. It's only use is to clarify the coders intent that the variable not be changed (which many consider dubious reason for its usage), and dealing with anonymous inner classes.

There is a lot of argument over whether the final modifier on the method itself has any performance gain since the methods will be inlined by the optimizing compiler at runtime anyway, regardless of the modifier. In this case it should also only be used to restrict the overriding of the method.

Final arguments in interface methods - what's the point?

It doesn't seem like there's any point to it. According to the Java Language Specification 4.12.4:

Declaring a variable final can serve
as useful documentation that its value
will not change and can help avoid
programming errors.

However, a final modifier on a method parameter is not mentioned in the rules for matching signatures of overridden methods, and it has no effect on the caller, only within the body of an implementation. Also, as noted by Robin in a comment, the final modifier on a method parameter has no effect on the generated byte code. (This is not true for other uses of final.)

---

Related Topics