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

Question

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 lt Integer gt  c    new ArrayList lt Integer gt               nullify c       assertNotNull c              final Collection lt Integer gt  c1   c      assertTrue c1 equals c        change c       assertTrue c1 equals c       private void change Collection lt Integer gt  c        c   new ArrayList lt Integer gt        public void nullify Collection lt   gt  t        t   null

User · Answer

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

User · Answer

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 lt Integer gt  createIntegerIterator final int from  final int to        return new Iterator lt Integer gt             int index   from          public Integer next                         return index                      public boolean hasNext                         return index  lt   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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  gt  0          A    B       if  i  gt  100          A    C       return A      Playing devil s advocate  what exactly is wrong with doing this

User · Answer

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

User · Answer

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

User · Answer

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    quot afterSet quot                       Override         public String showObjName                return obj name                        return myParam     public static class MyObj      String name    quot beforeSet quot       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  quot showObjName quot   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  quot CONFUSING   quot  Because they are all using the same  quot reference name quot  which is  quot obj quot   To avoid this  set it as  quot final quot  to avoid programmer do the  quot mistake-prone quot  code

User · Answer

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

User · Answer

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

User · Answer

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   quot tiger quot     void doSomething  String arg       String x   arg       Both variables now point to the same String object    x    quot elephant quot        This variable now points to a different String object    arg    quot giraffe quot       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    quot elephant quot       Compiler error  The final local variable x cannot be assigned     arg    quot giraffe quot        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    quot elephant quot      arg    quot giraffe quot       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  amp  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  gt  0          A    B       if  i  gt  100          A    C       return A      Playing devil s advocate  what exactly is wrong with doing this

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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   quot tiger quot     void doSomething  String arg       String x   arg       Both variables now point to the same String object    x    quot elephant quot        This variable now points to a different String object    arg    quot giraffe quot       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    quot elephant quot       Compiler error  The final local variable x cannot be assigned     arg    quot giraffe quot        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    quot elephant quot      arg    quot giraffe quot       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  amp  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt Integer gt  createIntegerIterator final int from  final int to        return new Iterator lt Integer gt             int index   from          public Integer next                         return index                      public boolean hasNext                         return index  lt   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

User · Answer

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 lt Integer gt  createIntegerIterator final int from  final int to        return new Iterator lt Integer gt             int index   from          public Integer next                         return index                      public boolean hasNext                         return index  lt   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

User · Answer

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 lt Integer gt  createIntegerIterator final int from  final int to        return new Iterator lt Integer gt             int index   from          public Integer next                         return index                      public boolean hasNext                         return index  lt   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

User · Answer

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

User · Answer

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

User · Answer

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    quot afterSet quot                       Override         public String showObjName                return obj name                        return myParam     public static class MyObj      String name    quot beforeSet quot       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  quot showObjName quot   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  quot CONFUSING   quot  Because they are all using the same  quot reference name quot  which is  quot obj quot   To avoid this  set it as  quot final quot  to avoid programmer do the  quot mistake-prone quot  code

User · Answer

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

User · Answer

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

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

Examples related to java

Examples related to pass-by-reference

Examples related to final

Examples related to pass-by-value