RFR: 8071571: Move substring of same string to slow path

[Remi Forax]

On 03/27/2015 11:01 PM, Martin Buchholz wrote:
> On Fri, Mar 27, 2015 at 2:57 PM, Roger Riggs <Roger.Riggs at 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