java.lang.StackOverflowError in Lowering

[Alessio Stalla]

On Wed, Jun 22, 2011 at 6:27 PM, Bob Foster <bobfoster at gmail.com> 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. :)

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.

Alessio