It is generally a good idea to restrict access to your variables as much as reasonably possible. For example make things private instead of publicand make variables final if they aren't supposed to change. I believe the same applies to method parameters, but I find actual practice of this to be extremely rare.
For example, no IDEs that I know of offer warnings for finality of method parameters, even though you should be able to tell easily if the parameter can be made final. Even core Java libraries don't make their method parameters final, even though they could; and I find it pretty rare for a 3rd party library to do this either.
Overall the benefits here are certainly relatively low, given that the scope is so small. Does it give enough benefits though to justify as a coding standard?
finalparameter, you can simply omitfinaland the code will work with the same behavior.finalis about what you cannot do, and thus what assumptions you can make. So instead you'd want examples of confusing or broken code that would have been disallowed had the parameter beenfinal. – Derek Elkins left SE Sep 27 '17 at 03:07finalon a method parameter prevents something from breaking. If I change an incomingintor object reference, nobody on the outside will see it, so why bother making it final? – user949300 Sep 27 '17 at 03:14finalanyways, so there's already the expectation that the parameter binding won't be mutated. Of course, when that expectation is violated, either intentionally or unintentionally, it becomes especially surprising. One of the benefits of usingfinalwhenever possible, is that when you don't use it, you are clearly communicating "something unusual is happening". Ultimately, at the very least for parameters, this is just a poorly chosen default by Java. – Derek Elkins left SE Sep 27 '17 at 03:31