Effectively final

[Sam Pullara]

The average joe doesn't need to use any of the things you are talking about. They implement the objects for frameworks and move on. No average Joe is using raw Erlang, Akka, Node.js or Scala with success. If you want to look at average Joe programming, look to J2EE,  RoR or PHP. No explicit concurrency. No asynchronous programming. Just rules and frameworks.

Java is a systems programming language and trying to remove that at a core level seems like the wrong path to me. If you want these features they are easy to add on top of the JVM as another language or as a Java library. True concurrent programming has always been an edge case and probably always will be. To make sure that people are doing it on purpose though, requires these types of restrictions. Much better to have someone use an AtomicInteger then be the next "I assigned the outputstream to my servlet field" bug.

Sam

On Aug 16, 2011, at 12:24 AM, Tim Fox wrote:

> 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
> 
>