3

In java8, variables are effectively final if we do not assign them again. So, it means if we are declaring a method and if we don't declare its parameters to be final, then they are effectively final if we don't assign them in the method definition. So, does making the parameters final make any difference in java8?

Raj Kumar
  • 73
  • 4
  • 5
    Yes, if you declare them final then you can't reassign them. If you don't then you can reassign them. IMHO, making method parameters final is just clutter anyway... – assylias May 10 '19 at 16:41
  • From a language design perspective, this is an interesting question. We have that 'final' on an instance variable serves a somewhat different purpose than 'final' on a method parameter. The language designers could have automatically used by-value variables placed in blocks that can escape their declaration. But, that seems confusing, so the design (mostly) works. "Mostly" because allowing "effectively final" parameters takes away much of the original intent: The final parameter is not used by the language; it's now just a syntactic reminder. – Thomas Bitonti May 10 '19 at 16:55

3 Answers3

3

IMO, the reason to mark a parameter final is to show that you are depending on it being final. This might be the case if you are using the parameter in a lambda expression or an inner class. Marking the parameter final tells the next programmer who comes along (or you a year from now) that there is code that relies on that parameter being final.

CryptoFool
  • 21,719
  • 5
  • 26
  • 44
  • What's the point then? In the 2 examples you give, changing the code and reassigning the parameter will create a compile error anyway, which is a clear sign that you've just broken something. – assylias May 10 '19 at 16:50
  • 1
    I am just pointing out that `final` serves as documentation. Why document anything? Why not just let the next programmer who comes along figure everything out from the most minimal code possible? If you're in a shop that follows the guideline of making it as hard as possible for other programmers, then you should not put `final` on any of your parameters if doing so is optional. - If you know a parameter needs to be `final`, if only effectively, why not make it explicit...why not make it perfectly clear? - If there were a downside, this would be a completely different discussion. – CryptoFool May 10 '19 at 17:09
  • Fair enough but I prefer a guideline that says you should not reassign parameters. I like this approach: https://stackoverflow.com/a/138990/829571 (although the very last sentence does not apply post Java 8). – assylias May 10 '19 at 17:47
0

No. it isn't effectively final unless you use it inside anonymous function or lambda expression. Not in normal methods, why should it be.

SpaceyBot
  • 482
  • 1
  • 4
  • 20
0

I use final the same way as you. To me it looks superfluous on local variables and method parameters, and it doesn't convey useful extra information.

One important thing is that strive to keep my methods short and clean, each doing a single task. Thus my local variables and parameters have a very limited scope, and are used only for a single purpose. This minimizes the chances of reassigning them inadvertently.

Moreover, as you surely know, final doesn't guarantee that you can't change the value/state of a (nonprimitive) variable. Only that you can't reassign the reference to that object once initialized. In other words, it works seamlessly only with variables of primitive or immutable types. Consider

final String s = "forever";
    final int i = 1;
    final Map<String, Integer> m = new HashMap<String, Integer>();

    s = "never"; // compilation error!
    i++; // compilation error!
    m.put(s, i); // fine

This means that in many cases it still doesn't make it easier to understand what happens inside the code, and misunderstanding this may in fact cause subtle bugs which are hard to detect

Tarek Rahman
  • 21
  • 4