Bug in javac and eclipse ??

[Dan Smith]

On Jan 22, 2014, at 11:36 AM, Markus Keller <markus_keller at ch.ibm.com> wrote:

> Dan Smith <daniel.smith at oracle.com> wrote on 2014-01-22 18:39:21 to 
> lambda-spec-experts at openjdk.java.net (where I can't answer):
> 
>> Can you clarify what incorrect assumptions you think were made?  I'm not 
>> seeing any new information in this thread.
>> 
>> I've tried to be very clear about where were at: sure, it would be 
>> convenient to do something here, but it's a complicated space and it 
>> deserves a lot more analysis before we commit to something.  It's at the 
>> top of our "potential future enhancements" list.
> 
> It's all in 
> http://mail.openjdk.java.net/pipermail/lambda-spec-observers/2013-December/000623.html 
> .
> 
> In 
> http://mail.openjdk.java.net/pipermail/lambda-spec-observers/2013-December/000620.html 
> , you wrote:
>> I've had quite a few discussions about this, and concluded that it is 
>> best not to do anything until we flesh out a potential "recursive lambda 
>> expression" feature in the future.  (In 8, local variables initialized 
>> with lambdas have a similar inability to directly refer to themselves.)
>> 
> This sounds like you were talking about lambda expressions that want to 
> refer to themselves (e.g. by referring to a 'this' that points to the 
> lambda or by referring to the target the lambda expression is assigned 
> to). But the problem is not such cases.
> 

> The problem is cases where a lambda occurs in a field initializer and 
> refers to a field of the same class (any field, not only the field that is 
> being initialized). This is not a self-reference, but a normal reference 
> to a field.

Okay.  I see what you're talking about now.  Please note:

1) The specific mechanism that we considered for recursive lambdas was not 'this', but was to allow references to a variable from its initializer:

Runnable r = () -> doSomethingWith(r);

A point I've been making is that it should be irrelevant whether this is a local variable or a field: if it's useful, we should figure out a rule that captures this use case and permit it for both fields and local variables.

Hopefully that helps to clarify how the two features -- treatment of names in lambdas in field initializers and treatment of fields in lambdas in local variable initializers -- are related.

2) The problem is not _just_ such cases (e.g., in Remi's example the field was not initialized by a lambda, but merely introduced a lambda in its initializer), but it certainly _includes_ such cases.

> There's nothing special about this situation, and 8.3.3 
> already handles this fine if the reference occurs in an anonymous class 
> that is functionally equivalent to the lambda.

And it would be possible to extend this behavior to lambdas, but as I've said, it is not obvious that this is the right course of action.  When it comes to names and scoping, lambdas behave differently in many respects from the equivalent anonymous classes.

> The spec says in a comment: "The restrictions above are designed to catch, 
> at compile time, circular or otherwise malformed initializations." The 
> situation at hand is not about malformed initializations.

Without care, there could definitely be malformed initializations that arise as a result of allowing this.  It's an open question whether these are tolerable or not.

A dumb example:

String s = ((Supplier<String>) () -> s + "a").get();

> 
> BTW, there's an editing bug in 8.3.3 of java-se-8-jls-fr-diffs.pdf: The 
> sentence and bullet list are printed twice.

In the copy I have, that seems to be intentional: one paragraph is for static fields, and the other for instance fields.

—Dan