Effectively final

Rémi Forax forax at univ-mlv.fr
Fri Aug 19 04:00:44 PDT 2011

On 08/19/2011 08:23 AM, Llewellyn Falco wrote:
>> Sorry, Llewellen, wrong again.
> Since we are going to get to details, let's start with my name is
> "Llewellyn"
>> 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.
> I was under the impression that "an instance of a class" was the definition
> of an Object, is that incorrect?

The SAM converted lambda is an object.
The lambda by itself is not an object,
see the meaning of this below.

>> A good way to think of this is as a boxing conversion; the lambda gets
> boxed into a SAM.
> By this logic, an autoboxed int would not be an object either, and yet
> public void foo(Integer i)
> {
>    System.out.print(i.byteValue());
> }
> works even when called with an int. it's almost as if it has become an
> object.

It's a kind boxing conversion with no unboxing,
so no way (at least no Java way) to get the unboxed lambda.
So you're right that this is not an autoboxing conversion,
it's just a boxing conversion.

>> Currently, there is no way to denote the unboxed lambda, but that doesn't
> make them the same thing.
>> (If you want to think "lambdas are objects" because that makes it simpler,
> feel free to, but please don't confuse everyone else with your
> approximations.)
> If there is no way to denote an unboxed lambda, then you MUST denote it as
> an Object. This is not an approximation, it is a reality. You might feel
> that reality is confining, but there is no escaping it.

You only access a lambda from outside as an object,
from inside, i.e in the body of the lambda, there is no 'this'
corresponding to the lambda itself.
A lambda is an anonymous function that can be converted
to an object using the SAM conversion.

>   Moreover, There is
> simply NO WAY in the current spec to say:
> public void MethodThatOnlyAcceptsLambdas(???? lambda)
> therefore, everything that consumes a lambdas MUST accept that they can be
> called with plain old 'never been autoboxed' objects. This means there is no
> contract in the language to say "immutable objects only"
> In short, as long as the following code is allowed
> abstract class ThisIsAnObject
> {
>     int counter = 0;
>     public int next(){  return counter++;}
>     public string foo();
> }
> ThisIsAnObject o = #{"clicked" + next() + "times};
> Has this code been disallowed?

Yes, it's disallowed. Because as you said, otherwise
the lambda has states so is an object.

> If not, Lambdas are objects.
> what about??
> Runnable r = #{ System.out.println(this.toString()); }
> and if this is still legal, what is your explanation about the meaning of
> "this" in a function that is not an object?

'this' is the enclosing object, like in any method.

class A {
   void foo() {
      Runnable r = #{ System.out.println(this.toString()); }

Here, 'this' is the instance of A which is the receiver of foo(),
so this.toString() calls A::toString() (unless there is a B that 
inherits from A :)

> For that matter, as long as this still compiles
> for(int i = 1; i<  10; i++)
> {
>      final int currentValue = i;
>      Runnable r = #{ System.out.println("foo" + currentValue); }
> }
> You now have an instance of a class with member variables.... which is an
> object.

the value of 'currentValue' is stored in an instance variable
only when the SAM conversion occurs, not before.
So r is an object but the thing between #{ and } is not an object.

> and once you have this, I don't think you'll be able to take it away... Has
> Java ever Removed functionality in latter versions?
> I can understand that you might not like this reality, but that doesn't make
> it less correct. Right now you seem to have the view that if we just ignore
> the current state and focus on where you want java to go in the future that
> will help it to get there.

I hope you now understand our position (the one of the expert group) better.

> I can only say that technique has not been successful for myself, and might
> explain some of the frustration I have had on this list
> Llewellyn Falco


More information about the lambda-dev mailing list