Effectively final effective?

[Mark Thornton]

Alex Blewitt wrote:
> On 24 Feb 2010, at 23:04, Mark Thornton wrote:
>
>   
>> Neal Gafter wrote:
>>     
>>> It isn't just the visual noise that people find so bothersome.  The
>>> restriction itself is also bothersome, and harder to work around.
>>>       
>> Yet would not many developers be surprised to discover that they 
>> couldn't change an apparently ordinary local variable because it had 
>> been captured by a lambda (or anonymous inner class) some lines previously.
>>     
>
> That's my concern too. The fact that it has to be final (save tricks like one-element arrays, atomic refs etc.) is part of documenting that restriction. Simply allowing it to be omitted doesn't change the fact that it is final.
>
> Would it be worthwhile asking the question of a larger audience to get their thoughts? Or have those at Sun/Oracle already done so at some point? As with 'most' other people, the set of who 'most' is is an interesting question, particularly since I wonder if the question had been asked in any other language than English :-)
>
> Alex
Another alternative would be to allow the variables to be mutated, but 
where a lambda (or inner class) captured a variable that was not 
effectively final, it would also implement a marker interface that 
concurrent libraries could detect. Concurrent code could either throw an 
exception or fall back to a sequential algorithm if the supplied lambda 
implemented the marker interface. If this approach is viable it would be 
more flexible and surprise fewer developers. Admittedly it leaves the 
onus on concurrent library developers to insert the check.

Mark