Effectively final

[Tim Fox]

On 15/08/2011 23:16, Neal Gafter wrote:
> On Mon, Aug 15, 2011 at 2:58 PM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     That's absolutely true.  But the bar is not, and should not be, "we
>     should add a language feature if there is some model in which that
>     feature makes sense."  The ability to point to examples where it would
>     be safe or sensible is a necessary, but not remotely sufficient,
>     condition to justify inclusion of a language feature.
>
>     The choice to exclude mutable local capture was not an oversight, but
>     the result of a reasoned tradeoff which includes cases like those you
>     allude to.
>
>
> "mutable local capture" is not a language feature.  Locals variables 
> are a feature.  Variable mutation (assignment) is a feature.  Lambdas 
> (closures) are a feature.
>
> The choice not to "add mutable local capture" was not a choice "not to 
> add" a language feature, because "mutable local capture" isn't a 
> language feature, it is the intersection of otherwise orthogonal 
> language features.  The choice to exclude mutable local capture was a 
> decision to design Java's language features in a non-orthogonal way, 
> by considering and defining the interactions of individual features on 
> a case-by-case basis by reference to use cases and their perceived 
> importance.  That's not always the best way to design a programming 
> language.
I quite agree. Mutable capture seems to have been excluded because it 
doesn't fit well with "the conventional Java wisdom", i.e. how 
multi-threaded Java programs are *currently* programmed in the Java 
world (i.e. code all your objects for concurrent access and protect them 
accordingly using the complicated set of Java concurrency tools so your 
program works correctly).

This seems to ignore other concurrency models where a different approach 
is taken. I.e. objects are partitioned into sets which are never 
executed concurrently by more than one thread. The actor model is a good 
and popular example of such an approach (See Erlang, Akka, Scala). Other 
hybrid models exist such as that used in node.x, which also partition 
objects into "islands of single-threadness". Some languages don't have 
good support for concurrency, so there's not much choice other than to 
apply such a concurrency model.

IMHO these models are going to get more and more popular, and that's 
actually a *good thing*, especially if we want to attract more 
lightweight web developers onto the JVM (which Java needs to do if it 
has a future outside of legacy applications). Concurrency is hard, and 
if your model allows you to code as single threaded and not have to 
reason about concurrency too much, that's a huge win. Once you know your 
code is single threaded then things like mutable local capture with 
closures become very useful and allow you to write scalable, concurrent 
programs in a safe and intuitive way.

I don't think this is some edge case. I believe, this is how people are 
going to write programs int the future. If anything, the way Java 
concurrency is currently done is going to become the edge case, since, 
frankly, it's too complex for the average Joe.
> http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html