Effectively final

[Brian Goetz]

The "at least for now" part of your observation is critical.  We have 
been very careful to preserve the ability to evolve past the current 
point.

You can model objects with functions; you can model functions with 
objects.  So, they must be the same thing, right?  (Logic whispers in 
our ear: if a implies b and b implies a, then a equiv b.)  But the 
reality is: not really.

The expert group has debated the "are lambdas functions or are they 
objects" extensively.  The reality is that, given many decisions Java 
has already made, it will never be 100% one way or the other.  But, the 
fundamental question we are asking ourselves is still: are they more 
like functions or more like objects?  This has driven answer to a number 
of questions.

Our position is: lambdas should be more like functions.  Yes, we've been 
modeling functions with objects for 15+ years, and have gotten used to 
that, but to "believe our own press releases" in this way and just say 
that lambdas are a nicer way of writing inner class instances would be a 
big mistake.  (Doing so would, for example, burden all lambdas with 
identity, when only a small fraction of lambdas would really need 
identity.)

This has driven a lot of decisions, such as "what do names (and this) 
mean in a lambda?"  We've tried to be consistent with the position of "a 
lambda is more like the body of an if block" than "a lambda is more like 
an inner class instance", though there have been places where we've been 
unable to do so (specifically, semantics of return: we tried introducing 
"yield" to mean local return, and the world cried bloody murder.)

One reason for this decision is not burdening lambdas with the sins of 
the past (e.g., identity); another is to preserve the opportunity to do 
more functional things later (like first-class function types, if they 
can be reified.)

So your "plain text reading of the spec" is correct, except that the 
current spec represents only a point on the path along the way.  You 
have nothing to go on that we might ever get farther along that path, 
except my statement that this is where we want to go, but I hope that 
counts for something.


On 8/18/2011 1:06 PM, Alessio Stalla wrote:
> On Thu, Aug 18, 2011 at 6:55 PM, Brian Goetz<brian.goetz at oracle.com>  wrote:
>> Sorry, Llewellen, wrong again.
>>
>> Lambdas are functions.  Functions are not objects.
>>
>> You are right that as currently specified for Java SE 8, lambdas happen
>> to always get SAM-converted to instances of classes.  That's as far as
>> you can take this statement.
>
> Well, as currently specified, lambdas only exist at the syntactic
> level; they're effectively syntactic sugar for anonymous inner
> classes. So in a sense they are objects; they denote objects. If in
> future the same syntax will be used to denote proper functions, then
> they will be functions, but until then, I don't see how can you say
> that lambdas are functions, since Java does not have functions.
>
>> A good way to think of this is as a boxing conversion; the lambda gets
>> boxed into a SAM.  Currently, there is no way to denote the unboxed
>> lambda, but that doesn't make them the same thing.
>
> It's not just that there's no way to denote the unboxed lambda;
> there's no way to represent it at runtime, either. Unboxed lambdas in
> Java are a purely abstract idea, at least for now.
>
> Alessio