java.lang.StackOverflowError in Lowering
brian.goetz at oracle.com
Wed Jun 22 10:03:33 PDT 2011
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. :)
More information about the lambda-dev