Skip to main content

Final as default modifier for method parameters

5 replies [Last post]
Joined: 2003-11-29

A common programming failures is accidently changing the value of a method parameter by mistyping. It can me resolved
by adding the final modifier to each parameter. But the list of parameters becomes very long.

I suggest a nonfinal modifier for method parameters.

Should there be a change in the java parser or is there a change to achieve this with Annotations?

Kind regards

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-11

Even if a language change was warranted, it isn't going to happen. It would break far too much existing code.

I would go farther and suggest that the design of Java is exactly backwards with respect to the "final" keyword. In other words, final should be implied. Rather than a final keyword, there should be a "mutable" keyword. Here's a good discussion on the value of final.

In an analogous manner, the default visibility should be "private" and the "package" keyword should be used to promote visibility when required. That change won't happen either.

Also, Java errs on the wrong side of assuming code will handle nulls properly.

While none of these changes is likely to happen to the language, a code-aware IDE like Eclipse or Netbeans could support at least the first two without too much work.

After working with Java for close to a decade, this seems obvious to me now. Then again, hindsight is 20/20, and I'm sure there is no shortage of Python people that would consider this all dead wrong. It may be dead wrong for them, but I'm more productive when the compiler catches my mistakes.

Joined: 2012-04-12

A bit old now, but I agree with coxcu. There would be too much damage to the existing codebase.

Some more info for those interest. Access Modifiers at IBM website, or intro to Modifiers at IT Learning

Access Modifiers
Java Modifiers

Joined: 2004-05-06

Hi Sebastian,

I make it part of my coding style now to use the final modifier on all method parameters. Yes it does lengthen the parameter code a bit but I have found the benefits are worth it. While I do agree that the value of method parameters should not be modified, a language change to accomodate enforcing this IMHO would not be worth it.

A very useful tool to enforce this coding style is CheckStyle ( It has plug-ins available for most popular IDEs and build systems (Ant, Maven, etc.) and I have set it up so it flags any non-final method parameter as a problem (it shows up as a warning in the IDE). This is very valuable for enforcing this style, expecially when I started coding this way and would forget to make method parameters final half the time.


Joined: 2003-07-08

Even better would be a code formatter that put in the final modifier automatically. I don't think there's one out at the moment that will do this, but Jalopy is open source. :) Jackpot should be able to do this as well.

Joined: 2003-06-18


I have found a naming convention to be quite effective in these cases. I use:

m_ : for member level variables
p_ : for method parameters

For example:

void setSomething( String p_strSomething )
m_strSomething = p_strSomething;

I have learnt I am somewhat alone in liking this (as it's very verbose), but it certainly helps you remember the scope/type of the variable in question.