First draft of translation document

Rémi Forax forax at
Wed May 19 02:35:11 PDT 2010

Le 19/05/2010 05:31, Neal Gafter a écrit :
> On Tue, May 18, 2010 at 6:02 PM, Rémi Forax<forax at>  wrote:
>>> Language features are not to be defined by the features of the VM.
>> Agree in general, but not in this specific case.
>> The frame object or any equivalent data structure should be managed by the
>> VM,
>> it's a stack allocated data structure. There is no need of an object header
>> or a vtable
>> for such data structure.
> These frame objects are not stack allocated.  They must be managed by
> the GC.  Thus, an object header is required.

The whole point of asSam() is to try to avoid the static footprint that 
you currently have with anonymous classes.
If the frame object is not know by the VM, the compiler have to generate 
a specific class for each frame object
thus we are falling in the same trap as anonymous classes.

>>> This is not proposing a pass-by-reference language feature.  It is
>>> describing a way to compile code that references ordinary mutable
>>> variables.  Mutable variables are definitely part of and in the spirit of
>>> Java.
>> Threse aren't that ordinary because you have to create a new keyword or if
>> you prefer a new semantics
>> for those kind of variables.
> Neither is needed.  While project lambda may elect to have a new
> keyword for other reasons, it is not necessary.  Neither are new
> semantics required.

The problem with shared variables is that you break the assumption
that you have sequential ordering of local variables.
I don't see why we should offer a feature with such semantics.

void f() {
   shared String s = "hello";
   Utils.perhapsRunInAnotherThread(#() {
     System.out.println(s); // may or may not prints null

The Java memory model is sufficiently complicated to not add more 



More information about the lambda-dev mailing list