By default, I want all my local variables and method parameters to be final. Unfortunately, the Java language designers chose a different default: variables&parameters are by default non-final, and final variables&parameters need to be declared with the final keyword. So I need to add lots of finals. (And obviously I don't do this manually, but have my IDE add them for me.)

So I end up with source code where every default case is marked, whereas exceptions to my preferred default are barely visible. For readability, I would like it to be the other way round, i.e. only non-final local variables and parameters should be marked/highlighted/annotated/...

Is this possible?

I'm open to solutions that integrate at different levels, e.g. folding within the editor, style checkers, build steps, etc...

  • 1
    Sometimes, you have to pay for the tradeoff between "boilerplate vs clarifying the intent".
    – Morwenn
    May 29, 2013 at 13:32

3 Answers 3


I think your intention in making all local variables final is very good practice, but doing so implicitly (i.e. not explicitly with the final keyword) is a bad idea.

Rather than worry about readability for yourself, think about future maintainers of your code: will anyone reasonably expect that reassigning a field without the final keyword will fail to compile?

It looks like you can automate the inclusion of final keywords in Eclipse during code generation, but using a style checker to enforce it may highlight more false positives than it's worth.

If you're open to exploring other languages and paradigms, many functional languages default to immutability.

  • +1 for Eclipse link, very powerful to manage final problem
    – cl-r
    May 29, 2013 at 14:10
  • I have the final keyword inserted for me where possible. The main drawback of this is however that there may be a variable that is non-final by accident, and I'm likely to overlook this.
    – oberlies
    May 29, 2013 at 15:44

The best solution I can imagine for this problem is to have the final keyword in the source files as normal, but have my editor hide them and instead highlight all declarations without final keyword. This would give me exactly what I want, and the files would still be plain Java.

Unfortunately, I don't know any IDE that has support for this. For Eclipse, there is a bug proposing this enhancement.


I think you need to read about the purpose of final and stop misusing it. http://en.wikipedia.org/wiki/Final_%28Java%29 The whole point of final is if you want to make a member of a class public (yet constant) rather than hide it behind a getter, Or if you want to put a method in a class and make it impossible to override, Or if you want to make a class unextendable. Using final for a slew of variables in a local function is a total abuse of the language (and is not going to give you some magical performance boost like you think since they still have to go onto the function stack!). What would make sense to do is create a class that holds all your final variables and just reference it in your local functions, or make final global variables. And as for adding the final keyword, just start all the variables with fnx_variablename and use search and replace to turn fnx_variablename to final fn_variablename; you should use some kind of convention to show they are final after all.

  • 3
    I think you misunderstand final. If it was public yet constant, it wouldn't make sense for it to be able to declare a final within the scope of a method. It is not about performance (though that can be a nice side effect) but rather conveying the intent of the code clearly to the next programmer who has to read it - "This value is set once and only once here" and be able to guarantee that contract throughout the scope of the variable.
    – user40980
    May 30, 2013 at 1:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.