On 03/27/2015 11:01 PM, Martin Buchholz wrote:
On Fri, Mar 27, 2015 at 2:57 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
Hi,
@Martin: does the final have some functional reason to be present?
I see it just bulks up the source, reducing readability. If it is useful
to improve performance then fine.
If you use the idiom
final Type foo = this.foo;
and leave out the final,
there is a risk of a maintainer assigning to foo and introducing a bug.
Maybe I should stop, since no one seems to understand it?
I really dislike this style,
If you put final on foo you should also put final
on len and on all parameters because following your idea a maintainer
may introduce a bug.
At that point, you have clutter the whole code with final everywhere for
a bug that happens rarely.
This kind of bugs (modifying a field that was loaded in a local
variable) should be catch by a lint tool (or/and IDEs)
and not by asking every developers to add final (randomly).
And final on a local variable has no impact on performance because it
doesn't appear in the generated bytecode.
Historical note: final was introduce with jdk 1.1 to make explicit that
the semantics of capturing a local variable in an anonymous class was by
copying the local variable value and not by capturing the variable
itself like in Lisp (Ruby, JavaScript, etc.). Since Java 8, you don't
need to declare local variables 'final' anymore because the compiler
enforces that captured variables are effectively final.
The other problem of final is that while final on a local variables is
futile, it's a very important concept on fields, and a awful lot of Java
devs doesn't make the difference between a field and a local variable
(both are variables right ?).
And every time a discussion about final on local variable sprung, I'm
quite sure that we (and i) just add more confusion :(
regards,
Rémi
