java.lang.StackOverflowError in Lowering

[Brian Goetz]

>> Java makes it awkward and tedious to return multiple results from a method
>> and something equivalent is needed to return even a single result from a
>> Runnable. Hence, Callable<T>, etc. Programs do need to do that. There are
>> plenty of use cases where local variable capture is a reasonable choice,
>> like SwingUtilities.invokeAndWait or CountDownLatch(1). I'm not sure
>> attitude helps people deal with this issue, though it has certainly helped
>> Project Lambda not deal with it. :)
>
> I used to think the same, but now I'm not so convinced anymore. My
> experience with closures comes from Lisp, where mutable variable
> capture is supported and used commonly enough that removing it would
> effectively damage the language. However, Lisp is not class-centered
> and lexical variable capture is most often employed to use functions
> as lightweight objects with a little state. In Java there's not much
> need for such a thing, since all code must be in a class anyway; and
> even if you don't want to add an extra class with a few fields, you
> can always use final Atomic* local variables. Furthermore, if you
> don't like atomic references in non-concurrent code, writing
> non-concurrent *Reference classes is trivial.

Also, the world has changed dramatically.  In the early days of Lisp, 
concurrency was merely a theoretical concern; now it is a mainstream 
concern.  The approach to summation (or reduction, more generally) 
inherent in the example being gently ridiculed here is a fundamentally 
serial idiom.  In 2011, adding / distorting language features to cater 
to fundamentally serial computational idioms would be downright silly.

Of course, the library work that is a companion to lambda, which would 
provide the map/reduce idioms that would obviate the motivation for this 
example, is not yet here.  But it is never too early to start 
discouraging the bad idioms.