[quote]It prevents no bugs at all and makes your code hideous.
[/quote]
Well I found it has helped a little.
For those who want to read up on the final keyword, this site is good on explaining the goodness :
http://renaud.waldura.com/doc/java/final-keyword.shtml
Don’t forget that final provides information that cannot otherwise be know to the runtime compiler.
Very little information the compiler can’t already know itself.
Cas
I’ve also started using final, at least on member variables. It saves me the time do a bunch of “find usages” when I want to change an existing class and I need to know what changes to take care of any side effects. Also encourages more immutable code, which I think is a good thing.
member variables - fine - has genuinely useful meaning such as immutable objects and known construction state (although there are caveats)
Local variables and parameters - code clutter the compiler already optimises anyway.
Cas
I’m anal and define methods ‘final’ even if they are implicitly final.
If a method is not final (either implicit or explicit), it cannot be inlined nor the method table indirection skipped. The runtime cannot know that it is never overwritten. Keep in mind the dynamic nature of Java. Say you have a package private class which has no subclass at time T. There are perfectly legal ways for a new class that does extend it at some future time to be introduced.
WRT members, it’s one less piece of information that the compiler must deduce. Variable lifetime and assignment analysis isn’t free.
Hm, I thought you knew a bit more about how Hotspot worked?
Cas
I’m assuming that HotSpot isn’t the only game in town. Yes, the deoptimization code base is pretty cool. (For others, HotSpot can treat non-final methods as final. If a new class is loaded and proves that assuming incorrect, the wrong code is ejected and recompiled).
It’s perfectly fine for people to either hate or like the final keyword on local vars or method parameters. It’s a code style and each programmer knows what code style works for them. The Java compiler removes it from local vars and params anyway, it has no value at runtime.
I generally skip final for methods that are implicitly final. Otherwise it depends on the API, during the design phase I usually use final everywhere until there’s a reason not to. Tests and actual usage of the API will dictate whether a method requires final or not. For public APIs though I try to be very careful with final usage, it can be very annoying for the API user.
I may try to create a “Java” with the mutable keyword and maybe operator overloading with MPS, when I have time.
I just want to distance myself from the performance argument. This is really bad and misunderstood reason to use final. There are plenty of non-final things which can prevent methods from being inlined and there is nothing to stop a compiler inlining a non-final method (such as if it’s reentrant).
People can come up with theoretical arguments as to why Java can’t optimize a non-final method or class, but because optimizations are performed at runtime there is also nothing to stop them being unrolled and re-optimized at runtime.
Google’s V8 JavaScript engine does this. It optimizes your code presuming a range of corner cases will not occur, which allows it to perform more aggressive optimizations. If you hit one of those corner case then it throws away the optimized code and you get terrible performance. But for 99.9% of JS out there this strategy works and improves performance. There is no reason why a Java runtime can’t do the same (and I believe HotSpot already does in some cases).
I also second that variables should be final unless declared ‘mutable’, and would also like to see non-final local variables colored differently. As Cas said there is nothing to stop you looking through looking for an assignment, especially with the variable highlighting you get in IDEs now. But I’d rather that I could be told this information in one place without having to look anywhere else. Final does this.
However for methods and classes I try to avoid using final unless I have a good reason to.
Personally can’t stand code with final littered all over the place, guess this is just one of those pet peeves that gets under programmers skins, much like the age old debate of whether an opening bracket of a method should be on the same line or the next line.
But yeah agreed that its just a matter of style.
However many that I have spoken to that use it are under the impression that it improves performance of the code somehow or that it reduces garbage.
I have found myself missing final local variables in C# when refactoring complex legacy code. It gives you a foolproof way of checking whether something is modified later in a far-too-large method.
[quote=“JL235,post:50,topic:35884”]
I think HotSpot can even do it without throwing away the optimized code path.
[quote=“JL235,post:50,topic:35884”]
IDEA supports using different styles for reassigned local variables and method parameters. Not exactly what you describe but equally useful.
@kapta: Have you checked if there’s a plugin for your favorite IDE that allows you to hide final from local vars and params? Would be nice for people that dislike final.
Perhaps deal with the real problem and shorten the method instead?
Quite! Big methods make code hard to read and understand. I know because loads of my code looks like this 
Cas
That’s another reason I like final method parameters actually. When I find myself wanting to reassign a parameter, I always try to rethink wth it is I’m trying to do (and usually split a method in smaller ones). With many small methods there’s almost never a need to reassign a parameter.
edit: Btw, my IDE automatically generates the final keyword when it generates method stubs, so I don’t actually waste time typing it. As for readability, I don’t mind the final keywords on methods with few arguments and on methods with lots of arguments I usually need to go through the javadoc to figure out what’s happening (lots of arguments is usually a sign of bad design anyway).