Develop Reference

What is the purpose of declaring method parameters final? [duplicate]

This question already has answers here:
Why Final is used in method parameters [duplicate]
(6 answers)
Why should I use the keyword "final" on a method parameter in Java?
(12 answers)
Closed 5 years ago.
So I can fully understand why you may want to make your class final. Imagine String class not being final, and you have a library, in which you have a method that takes a String as an argument and depends on the length() method for some operation, but someone extends the String class and overrides the length to return -1 always..
But I can not figure out why anyone would ever declare a parameter of a method final. Java is pass by value anyway, so if the parameter is a primitive, it is already final (in a sense).. And if you are passing a Reference Type does it guarantee anything to the caller of the method? I do not think so..
void foo(final List<Object> o) {
o.add(new Object());
} // oops?
So final prevents the following:
void foo(final List<Object> o) {
o = new ArrayList();
}
But why would I ever want to do this anyway? I can always create a new variable, and it does not assign a new Object to the caller 's variable anyway? (I mean, I can not change what the callers reference refers to anyway, even if the parameter was not declared final..)
My question is, what is the purpose of a final parameter in a method declaration? Is it for the caller? Does it guarantee anything?
I also find strange that the following will compile fine:
public interface MyInterface {
void foo(final Object o);
}
class MyImpl implements MyInterface {
#Override
public void foo(Object o) { // final in interface, not final in impl..
}
}
but maybe it will make sense once I understand the main question I have.

Sometimes, it helps the fellow programmers or maintenars that they should not change the value of that variable.
Ex: Imagine a method taking a string parameter. Imagine that it a very long method having 1000 lines of code. If the parameter is not marked as final, the second programmer see an opportunity of changing the value in it. The first programmer resumes the work on the method while not having the knowledge that the variable is assigned a new value.
Making it final will fully assure the first programmers intention to be passed on to second.
Apart from this, if you need to use this variable in any of anonymous class in that method, you can't use it unless it is final.
Hope this helps.

It doesn't guarantee anything to the caller either way (regardless whether the argument is a primitive type or a reference type).
A method argument is a local variable whose value is initialized by the caller of the method. Making it final means the body of the method cannot assign a new value to that variable locally, so it only makes a different within the body of the method (since assigning a new value to such a variable within the method body would make no different for the caller of the method).
It ensures that any code in the method's body that uses the value of the argument would use the original value passed by the caller and not some different value that was assigned to it within the method body.

Final int parameter used in anonymous Runnable

I am wondering if I use correct method to call something in different thread.
I am doing it on Android, but think it is generic Java question.
I have method with some parameters. Lets say they are int.
class Main1 {
public static void mainOnlyWork(int x, int y) {
// not important here.
}
}
class Test {
Handler mHandler;
// called from main thread, stored as reference.
public Test() {
mHandler = new Handler();
}
public static void callInMainThread(final int x, final int y) {
mHandler.post(new Runnable() {
public void run() {
Main1.mainOnlyWork(x, y);
}
});
}
Now my question is, is it safe to use final ints to create anonymous runnable without any class members? If I omit final keywords for x and y parameters, Eclipse will complain. It seems to me, that is intended to use only constant numbers in such cases. If I pass not a constant, is it ok? Does Java "make" it constant by passing to this function?
But I want to call Test.callInMainThread from native using JNI. There is no way Java can tell if those numbers are constants or not in my opinion. Can I trust Java to make some magic? Will it always work this way?
I think maybe I have to create proxy class, like:
private abstract RunnableXY implements Runnable {
public RunnableXY(int x, int y) {
this.x = x;
this.y = y;
}
public int x;
public int y;
public abstract void run();
}
And call method would use:
public static void callInMainThread(final int x, final int y) {
mHandler.post(new RunnableXY(x,y) {
public void run() {
Main1.mainOnlyWork(this.x, this.y);
}
});
}
This way, i protect values against garbage collecting until runnable is used and dropped away. Do I have to create wrappers, or is marking final x in method parameters safe? When I try it, final keyword works just fine. However in threads, I do not think if it works now is reason it will work always as well. Does it work always with final? How is it made if it does? Would there be difference if parameter is not primitive type, but Object?
Update:
I already understand what final means in Java. That is not point of question. Point of question is where is scope of variables used in creation of Runnable. They are locals, that means after end of function their value cannot be referenced. Where are that values stored then, when Runnable object is passed to other thread and waits to be executed?

Internally a copy of parameters and local variables (residing on the method call stack) is taken in the thread. This is because after the method call is finished, the thread still lives.
And the variables are required to be final, to forbid overwriting the original variables in the method, which would cause having a different version in the thread. Which is simply misleading. So it is a matter of letting both versions of the same name mean the same thing.
Careful language design.
(Simplified somewhat, not naming symmetrically reversed cases, where the same holds.)

Starting with the basics: Java makes copies when you pass parameters. The x and y that your method receives are not the original variables that are passed in, they are copies of the original values. When you declare a method like this the values that you pass in don't have to be constants, but the copies that the method receives are1:
callInMainThread(final int x, final int y) { ..... }
Second: No, you don't have to make wrappers. When you access variables that are local to the outside scope the Java compiler automatically generates fields to store them, just like the wrappers you created manually. This is transparent to you.
One reason why you can't omit final is because Java doesn't implement any mechanism for transferring changes to the value of the variable between the local variable of the method and the generated field in the anonymous class. Also, the anonymous class may live longer than the method call. What happens if the anonymous class reads or writes the variable after the method has returned? If the variable is not final you can't read its value anymore or write into it.
1 Actually final variables are not constants. You can assign different values to them but only once. The value of final method parameters is assigned when the method is called, so they are pretty much constant for the duration of the method.

Primitives types are always passed by value. Even if you modify them inside a method, their original values (outside the method) are never changed. So yes, it is safe because these values are local to the method (be them final or not).
About final keyword in parameters, it actually only impedes you from re-assigning the value, it has no other purpose. This is for mere code safety. Parameters are always passed by value in Java (object references are passed by value too), so no matter what, any re-assigning will be local to the method. Once the method has finished, all re-assigning you've done in the method will fade away. For example, there's no difference between
public void test(String a) {
a = "Hello";
}
and
public void test(final String a) {
a = "Hello";
}
except that compiler will raise an error in the second case. In first case when test() method finishes a will be restored to original value (it will not be "Hello"). So effectively final in parameters make the parameter "constant" (watch out that for objects: you can still modify the object state, but not the reference of the object).
final keyword is required in anonymous classes because you're referencing a variable in another class scope (in your case, your anonymous Runnable instance is referencing Main1 instance variables). So if this is run in another thread and they're not final, you could overwrite the original reference for the duration of the method. This will make each thread reference different objects with same variable name, which is confusing, and thus it was blocked in the language design.
You don't have to create any wrappers or additional references. Parameters are already referenced for the duration of the method and will not be garbage-collected.

Is there a name for "this" in Java?

Eclipse will give an error, "The left-hand side of an assignment must be a variable", when I try something like:
public class Thing{
String a1;
int a2;
public void meth(){
Thing A = new Thing();
this = A;
}
}
I had to assign each variable (this.a1 = A.a1; this.a2 = A.a2;) as a work around.
Are there other ways to do this without going through each variable field?
And if this is not a variable what is it called?

this is a pseudo-variable that points to the current instance of the object, it can not be reassigned. It's also considered a keyword in the language, according to section §3.9 of the Java Language Specification.

No, there is no easy shortcut.
And if "this" is not a variable what is it called?
this is not a variable, it's a keyword.
Even though this is special, in many respects it acts like a reference. Therefore, for consistency, this = A would have to be a reference assignment, which doesn't quite make sense.
You seem to be expecting this = A to perform a field-by-field copy from A to this, and indeed Java's designers could choose do that in this case. However, this would be inconsistent with other reference assignments, and the overall benefits of having this as an exception are not at all clear.

this refers to this instance of the class.
You cannot assign to this

this is a java reserved keyword which refers to the current object. its not a variable its a java reserved keyword.
so this = A; is invalid. using this keyword we can refer to any instance variable or method of the current object. you have to refer to the instance variable like:
this.a1 = A.a1;
From Doc:
The most common reason for using the this keyword is because a field
is shadowed by a method or constructor parameter.

You can't assign to this in Java. It's not a variable; it's a keyword.
One thing you might consider, if you don't need a particular instance, is just returning your new instance.
public class Thing{
String a1;
int a2;
public Thing meth(){
Thing A = new Thing();
return A;
}
}
and you'd use it like
whatever = whatever.meth();

According to java lang spec §15.8.3 this is a keyword that is either an expression or statement
When used as a primary expression this denotes a value that is a reference to the object for which the instance method was invoked.
Expression: Something which evaluates to a value. Example: x++
The keyword this is also used in a special explicit constructor invocation statement
Statement: Syntactic elements that control the execution of a program, which are executed for their effect and do not have values Example: if (true)
In either case it is not a variable
Variable: A storage location with an associated type
In your case this is an expression and not a variable. But for all intents an purposes just call it a keyword
Keyword: A character sequence, formed from ASCII letters, are reserved for use ... that cannot be used as a variable name

this refers to the owner of the method.
In this case, the owner is the object itself.
Sometime, this may not refer to the class that you are writing code. Such as in the annoymous class. A common example is the anonymous listener.
button.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
this; // refers to the ActionListener
}
}
);
In addition, you can return this can do method chaining. Supposed you have a class called Homework and it has a method addTask.
public Homework addTask(String task){
return this;
}
you can call the addTask method like
homework.addTask("a").addTask("b").addTask("c");

I think the OP is asking for the ability to assign the contents of one object to another, rather than to assign a new value to the "this" pointer. C++ has this ability -- you can override the assignment operator -- but Java has no such ability.
It would be a nice feature to have in some occasional cases, but it's simply not currently possible, and it doesn't really fit the Java "mold" to provide the function in the future.
The capability would be more useful (and there would be more motivation to provide it) if Java allowed objects to be embedded in other objects (vs simply embedding referenced), but that's not in the cards either.

There is no1 way to copy the values of all fields from one instance onto another in the basic Java language. And you should typically not need it. You can most often just replace the reference to the new instance or work directly on the target instance.
In your case when you want to reset all fields of a object to the initial values (and there is seldomly a need for it) you typically use a reset method which eighter works on its own instance or is a static one working on any given object.
So
class A {
String a1; int a2;
void reset() { a1 = ""; a2 = 0; }
}
would be used as
A a = new A();
// modify a
a.reset();
and
class A {
String a1; int a2;
static void reset(A anotherA) { anotherA.a1 = ""; anotherA.a2 = 0; }
}
and use it like:
A.reset(a);
In both cases it makes sense to use the reset method also for setting the initial values in the constructor: A() { A.reset(this); } or A() { this.reset(); }
1 actually there are some libraries to do it, and you can code it with the help of reflection, the only reason I see it is used is to implement a clone() method or for some kind of wrapping/stubbing.

It sounds to me like what you're trying to do is have a method that reinitializes your object, i.e., set's it back to it's initial values. That's why you want to create a new object, and assign it to the current object, right?
If that's the case, let's try a different way of doing it, since, as has been said, you can't reassign this.
What if, instead of doing that, you tried something like this:
public class Thing {
String a1;
int a2;
public Thing() {
this.meth();
}
public void meth() {
this.a1 = "a1";
this.a2 = 2;
}
}
This way, Thing.meth() actually initializes your object, and the constructor calls it when the object is created. Then you can call it again whenever you'd like.

==Disclaimer, I don't know java==
You would want to assign manually.
I'm not sure why you are trying to create a new instance of Thing inside Thing, but as you don't set the values of a1 and a2 you would need to assign them the way you did.
this is a reserved keyword pointing the class object it is inside.
For example, if you wanted to have another function named fish() your code may look something like this.
public class Thing{
String a1;
int a2;
public Thing meth(){
Thing A = new Thing();
return A;
}
public Thing fish(){
this.a1 = "foo";
this.meth();
return A;
}
}

When you do this = stuff; you are trying to replace the current object instance reference (in this case, the one that you are initializing in the constructor) with another thing, and (in the particular case of java) thats illegal and the language forbids you of doing it.
Think about it, if you could replace the reference to your current instance just like that, then you could incur in some serious memory and security problems (the reference to the constructed object will be lost and overrided by some unknown object).
What is totally valid is referencing members of your current object using the . operator, because they are owned by this, so no problems should arise (at least not evident ones).
The JVM has some inner security measures (e.g., method max stack size verification, class file format validation, etc) that prevents from easy binary manipulation and are enforced by the language syntax. This could be seen as one of those.

Null Object When Passed Into An Anonymous Inner Class

When passing a final object (A String in the code below) it shows up as null when printed from the anonymous inner class. However, when a final value type or straight final String is passed in, its value is correctly displayed. What does final really mean in context of the anonymous inner class and why is the object passed null?
public class WeirdInners
{
public class InnerThing
{
public InnerThing()
{
print();
}
public void print(){
}
}
public WeirdInners()
{
final String aString = "argh!".toString();
final String bString = "argh!";
System.out.println(aString);
System.out.println(bString);
InnerThing inner =new InnerThing(){
public void print()
{
System.out.println("inner"+aString); // When called from constructor, this value is null.
System.out.println("inner"+bString); // This value is correctly printed.
}
};
inner.print();
}
public static void main(String[] args)
{
WeirdInners test1 = new WeirdInners();
}
}
This is very strange behavior to me because the expectation is that the String is an object, why does calling toString() change things?
Other info: this behavior is only observed using Java 1.4, not in Java 5. Any suggestions on a workaround? Not calling toString() on an existing String is fair enough, but since this is only an example, it has real world implications if I perform it on a non-String object.

If you check the section on compile-time constants in the JLS, you'll see that calling .toString() does make a difference. As does nonsense like prefixing with false?null+"":.
What is important here is the relative ordering of setting the fields that are closed over and the constructor. If you use -target 1.4 or later (which is not the default in 1.4!) then the fields will be copied before calling the super. With the spec before 1.3 this was illegal bytecode.
As is often the case in these cases, javap -c is useful to see what the javac compiler is doing. The spec is useful for understanding why (should you have sufficient patience).

My guess would be that you trigger undefined behaviour when the constructor of InnerThing() passes (implicitly) its this to the print method of an anonymous subclass of InnerThing while the object is not fully constructed. This this in turn relies on an implicit reference to the this of WierdInners.
Calling .toString() moves initialisation of aString from compile time to runtime. Why the undefined behaviour differs between Java 1.4 and 1.5 is a JVM implementation detail probably.

It is dangerous to invoke overridden methods from a superclass constructor, as they will be called before the subclass-part of the object is initialized.
Moreover, an inner class accessing final variables of an enclosing scope will actually access copies of those variables (that's why they need to be final), and these copied fields reside in the anonymous subclass.
I suspect the reason bString is treated differently is that its value is known at compile time, which allows the compiler to inline the field access in the subclass, making the time that field is initialized irrelevant.

Why should I use the keyword "final" on a method parameter in Java?

I can't understand where the final keyword is really handy when it is used on method parameters.
If we exclude the usage of anonymous classes, readability and intent declaration then it seems almost worthless to me.
Enforcing that some data remains constant is not as strong as it seems.
If the parameter is a primitive then it will have no effect since the parameter is passed to the method as a value and changing it will have no effect outside the scope.
If we are passing a parameter by reference, then the reference itself is a local variable and if the reference is changed from within the method, that would not have any effect from outside of the method scope.
Consider the simple test example below.
This test passes although the method changed the value of the reference given to it, it has no effect.
public void testNullify() {
Collection<Integer> c = new ArrayList<Integer>();
nullify(c);
assertNotNull(c);
final Collection<Integer> c1 = c;
assertTrue(c1.equals(c));
change(c);
assertTrue(c1.equals(c));
}
private void change(Collection<Integer> c) {
c = new ArrayList<Integer>();
}
public void nullify(Collection<?> t) {
t = null;
}

Stop a Variable’s Reassignment
While these answers are intellectually interesting, I've not read the short simple answer:
Use the keyword final when you want the compiler to prevent a
variable from being re-assigned to a different object.
Whether the variable is a static variable, member variable, local variable, or argument/parameter variable, the effect is entirely the same.
Example
Let’s see the effect in action.
Consider this simple method, where the two variables (arg and x) can both be re-assigned different objects.
// Example use of this method:
// this.doSomething( "tiger" );
void doSomething( String arg ) {
String x = arg; // Both variables now point to the same String object.
x = "elephant"; // This variable now points to a different String object.
arg = "giraffe"; // Ditto. Now neither variable points to the original passed String.
}
Mark the local variable as final. This results in a compiler error.
void doSomething( String arg ) {
final String x = arg; // Mark variable as 'final'.
x = "elephant"; // Compiler error: The final local variable x cannot be assigned.
arg = "giraffe";
}
Instead, let’s mark the parameter variable as final. This too results in a compiler error.
void doSomething( final String arg ) { // Mark argument as 'final'.
String x = arg;
x = "elephant";
arg = "giraffe"; // Compiler error: The passed argument variable arg cannot be re-assigned to another object.
}
Moral of the story:
If you want to ensure a variable always points to the same object,
mark the variable final.
Never Reassign Arguments
As good programming practice (in any language), you should never re-assign a parameter/argument variable to an object other than the object passed by the calling method. In the examples above, one should never write the line arg = . Since humans make mistakes, and programmers are human, let’s ask the compiler to assist us. Mark every parameter/argument variable as 'final' so that the compiler may find and flag any such re-assignments.
In Retrospect
As noted in other answers…
Given Java's original design goal of helping programmers to avoid dumb mistakes such as reading past the end of an array, Java should have been designed to automatically enforce all parameter/argument variables as 'final'. In other words, Arguments should not be variables. But hindsight is 20/20 vision, and the Java designers had their hands full at the time.
So, always add final to all arguments?
Should we add final to each and every method parameter being declared?
In theory, yes.
In practice, no.➥ Add final only when the method’s code is long or complicated, where the argument may be mistaken for a local or member variable and possibly re-assigned.
If you buy into the practice of never re-assigning an argument, you will be inclined to add a final to each. But this is tedious and makes the declaration a bit harder to read.
For short simple code where the argument is obviously an argument, and not a local variable nor a member variable, I do not bother adding the final. If the code is quite obvious, with no chance of me nor any other programmer doing maintenance or refactoring accidentally mistaking the argument variable as something other than an argument, then don’t bother. In my own work, I add final only in longer or more involved code where an argument might mistaken for a local or member variable.
#Another case added for the completeness
public class MyClass {
private int x;
//getters and setters
}
void doSomething( final MyClass arg ) { // Mark argument as 'final'.
arg = new MyClass(); // Compiler error: The passed argument variable arg cannot be re-assigned to another object.
arg.setX(20); // allowed
// We can re-assign properties of argument which is marked as final
}
record
Java 16 brings the new records feature. A record is a very brief way to define a class whose central purpose is to merely carry data, immutably and transparently.
You simply declare the class name along with the names and types of its member fields. The compiler implicitly provides the constructor, getters, equals & hashCode, and toString.
The fields are read-only, with no setters. So a record is one case where there is no need to mark the arguments final. They are already effectively final. Indeed, the compiler forbids using final when declaring the fields of a record.
public record Employee( String name , LocalDate whenHired ) // 🡄 Marking `final` here is *not* allowed.
{
}
If you provide an optional constructor, there you can mark final.
public record Employee(String name , LocalDate whenHired) // 🡄 Marking `final` here is *not* allowed.
{
public Employee ( final String name , final LocalDate whenHired ) // 🡄 Marking `final` here *is* allowed.
{
this.name = name;
whenHired = LocalDate.MIN; // 🡄 Compiler error, because of `final`.
this.whenHired = whenHired;
}
}

Sometimes it's nice to be explicit (for readability) that the variable doesn't change. Here's a simple example where using final can save some possible headaches:
public void setTest(String test) {
test = test;
}
If you forget the 'this' keyword on a setter, then the variable you want to set doesn't get set. However, if you used the final keyword on the parameter, then the bug would be caught at compile time.

Yes, excluding anonymous classes, readability and intent declaration it's almost worthless. Are those three things worthless though?
Personally I tend not to use final for local variables and parameters unless I'm using the variable in an anonymous inner class, but I can certainly see the point of those who want to make it clear that the parameter value itself won't change (even if the object it refers to changes its contents). For those who find that adds to readability, I think it's an entirely reasonable thing to do.
Your point would be more important if anyone were actually claiming that it did keep data constant in a way that it doesn't - but I can't remember seeing any such claims. Are you suggesting there's a significant body of developers suggesting that final has more effect than it really does?
EDIT: I should really have summed all of this up with a Monty Python reference; the question seems somewhat similar to asking "What have the Romans ever done for us?"

Let me explain a bit about the one case where you have to use final, which Jon already mentioned:
If you create an anonymous inner class in your method and use a local variable (such as a method parameter) inside that class, then the compiler forces you to make the parameter final:
public Iterator<Integer> createIntegerIterator(final int from, final int to)
{
return new Iterator<Integer>(){
int index = from;
public Integer next()
{
return index++;
}
public boolean hasNext()
{
return index <= to;
}
// remove method omitted
};
}
Here the from and to parameters need to be final so they can be used inside the anonymous class.
The reason for that requirement is this: Local variables live on the stack, therefore they exist only while the method is executed. However, the anonymous class instance is returned from the method, so it may live for much longer. You can't preserve the stack, because it is needed for subsequent method calls.
So what Java does instead is to put copies of those local variables as hidden instance variables into the anonymous class (you can see them if you examine the byte code). But if they were not final, one might expect the anonymous class and the method seeing changes the other one makes to the variable. In order to maintain the illusion that there is only one variable rather than two copies, it has to be final.

I use final all the time on parameters.
Does it add that much? Not really.
Would I turn it off? No.
The reason: I found 3 bugs where people had written sloppy code and failed to set a member variable in accessors. All bugs proved difficult to find.
I'd like to see this made the default in a future version of Java. The pass by value/reference thing trips up an awful lot of junior programmers.
One more thing.. my methods tend to have a low number of parameters so the extra text on a method declaration isn't an issue.

Using final in a method parameter has nothing to do with what happens to the argument on the caller side. It is only meant to mark it as not changing inside that method. As I try to adopt a more functional programming style, I kind of see the value in that.

Personally I don't use final on method parameters, because it adds too much clutter to parameter lists.
I prefer to enforce that method parameters are not changed through something like Checkstyle.
For local variables I use final whenever possible, I even let Eclipse do that automatically in my setup for personal projects.
I would certainly like something stronger like C/C++ const.

Since Java passes copies of arguments I feel the relevance of final is rather limited. I guess the habit comes from the C++ era where you could prohibit reference content from being changed by doing a const char const *. I feel this kind of stuff makes you believe the developer is inherently stupid as f*** and needs to be protected against truly every character he types. In all humbleness may I say, I write very few bugs even though I omit final (unless I don't want someone to override my methods and classes). Maybe I'm just an old-school dev.

Short answer: final helps a tiny bit but... use defensive programming on the client side instead.
Indeed, the problem with final is that it only enforces the reference is unchanged, gleefully allowing the referenced object members to be mutated, unbeknownst to the caller. Hence the best practice in this regard is defensive programming on the caller side, creating deeply immutable instances or deep copies of objects that are in danger of being mugged by unscrupulous APIs.

I never use final in a parameter list, it just adds clutter like previous respondents have said. Also in Eclipse you can set parameter assignment to generate an error so using final in a parameter list seems pretty redundant to me.
Interestingly when I enabled the Eclipse setting for parameter assignment generating an error on it caught this code (this is just how I remember the flow, not the actual code. ) :-
private String getString(String A, int i, String B, String C)
{
if (i > 0)
A += B;
if (i > 100)
A += C;
return A;
}
Playing devil's advocate, what exactly is wrong with doing this?

One additional reason to add final to parameter declarations is that it helps to identify variables that need to be renamed as part of a "Extract Method" refactoring. I have found that adding final to each parameter prior to starting a large method refactoring quickly tells me if there are any issues I need to address before continuing.
However, I generally remove them as superfluous at the end of the refactoring.

Follow up by Michel's post. I made myself another example to explain it. I hope it could help.
public static void main(String[] args){
MyParam myParam = thisIsWhy(new MyObj());
myParam.setArgNewName();
System.out.println(myParam.showObjName());
}
public static MyParam thisIsWhy(final MyObj obj){
MyParam myParam = new MyParam() {
#Override
public void setArgNewName() {
obj.name = "afterSet";
}
#Override
public String showObjName(){
return obj.name;
}
};
return myParam;
}
public static class MyObj{
String name = "beforeSet";
public MyObj() {
}
}
public abstract static class MyParam{
public abstract void setArgNewName();
public abstract String showObjName();
}
From the code above, in the method thisIsWhy(), we actually didn't assign the [argument MyObj obj] to a real reference in MyParam. In instead, we just use the [argument MyObj obj] in the method inside MyParam.
But after we finish the method thisIsWhy(), should the argument(object) MyObj still exist?
Seems like it should, because we can see in main we still call the method showObjName() and it needs to reach obj. MyParam will still use/reaches the method argument even the method already returned!
How Java really achieve this is to generate a copy also is a hidden reference of the argument MyObj obj inside the MyParam object ( but it's not a formal field in MyParam so that we can't see it )
As we call "showObjName", it will use that reference to get the corresponding value.
But if we didn't put the argument final, which leads a situation we can reassign a new memory(object) to the argument MyObj obj.
Technically there's no clash at all! If we are allowed to do that, below will be the situation:
We now have a hidden [MyObj obj] point to a [Memory A in heap] now live in MyParam object.
We also have another [MyObj obj] which is the argument point to a [Memory B in heap] now live in thisIsWhy method.
No clash, but "CONFUSING!!" Because they are all using the same "reference name" which is "obj".
To avoid this, set it as "final" to avoid programmer do the "mistake-prone" code.