java.lang.StackOverflowError in Lowering

[Brian Goetz]

The problem is not with local variable capture -- but *mutable* local 
variable capture.  There are safety reasons why we didn't support it in 
the language.  Faking out the compiler to subvert these safety 
motivation is a bad idea, and as Ali clearly knows better, he properly 
got called on it :)  You can call that 'attitude' if you like, or you 
could put it in the same category as when your buddies take your car 
keys when you've been drinking.

There's a difference between "the language won't let me make a new 
primitive for 'complex', so I'll make a class for it" (which is working 
*with* the language) and "the language won't let me capture mutable 
locals, so I'll refactor my code so the compiler can't see what I'm 
doing" (which is working *against* the language.)  The array trick is 
clearly in the latter category.  We can't completely stop people from 
hurting themselves, but if discouraging them will help, we should do that.


On 6/22/2011 12:27 PM, Bob Foster wrote:
> On Wed, 22 Jun 2011 10:31:29 -0400 Brian Goetz wrote:
>
>>  And for using the one-element-array trick to work around the mutable
>>  capture restriction, your license to code in Java has been permanently
>>  revoked.  Please turn in your keyboard, and security will escort you out
>>  of the building.
>
> 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. :)
>
> Bob