From sam.munkes at gmail.com  Sat Jan  3 00:07:32 2015
From: sam.munkes at gmail.com (Sam Munkes)
Date: Fri, 2 Jan 2015 16:07:32 -0800
Subject: Generic ype inference with lower bounded types
Message-ID: <CABjcb6VRM8xoyUeS_TeBQX-V+_Hqws_=7ia6QtyGrBWtMw0j+w@mail.gmail.com>

Hi Guys,

A colleague of mine recently posted the following question to
StackOverflow:
http://stackoverflow.com/questions/27652867/java-type-inference-with-lower-bounded-types

Does anyone on the list have insight into why the compiler does not infer
lower bounded types?

static class Test {
    static <T> T pick(T one, T two) {
        return two;
    }

    static void testUpperBound() {
        List<? extends Integer> extendsInteger = new ArrayList<>();

        // List<? extends Integer> is treated as a subclass of List<?
extends Number>
        List<? extends Number> extendsNumber = extendsInteger;

        // List<? extends Number> is inferred as the common superclass
        extendsNumber = pick(extendsInteger, extendsNumber);
    }

    static void testLowerBound() {
        List<? super Number> superNumber = new ArrayList<>();

        // List<? super Number> is treated as a subclass of List<? super
Integer>
        List<? super Integer> superInteger = superNumber;

        // The inferred common type should be List<? super Integer>,
        // but instead we get a compile error:
        *superInteger = pick(superNumber, superInteger);*

        // It only compiles with an explicit type argument:
        superInteger = Test.<List<? super Integer>>pick(superNumber,
superInteger);
    }
}


Thanks

--
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150102/5347defc/attachment.html>

From maurizio.cimadamore at oracle.com  Sat Jan  3 00:41:13 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 03 Jan 2015 00:41:13 +0000
Subject: Generic ype inference with lower bounded types
In-Reply-To: <CABjcb6VRM8xoyUeS_TeBQX-V+_Hqws_=7ia6QtyGrBWtMw0j+w@mail.gmail.com>
References: <CABjcb6VRM8xoyUeS_TeBQX-V+_Hqws_=7ia6QtyGrBWtMw0j+w@mail.gmail.com>
Message-ID: <54A73AA9.5010603@oracle.com>

Hi Sam,
This works in JDK 8 (I think there's even a comment in SO saying that). 
Long story short, Java 5/6/7 inference typically ignored inference 
constraints coming from lower bounds; the treatment in Java 8 is much 
more consistent - as a result this program compiles as you'd expect 
(assuming you don't use -source 7).

Maurizio

On 03/01/15 00:07, Sam Munkes wrote:
> Hi Guys,
>
> A colleague of mine recently posted the following question to 
> StackOverflow: 
> http://stackoverflow.com/questions/27652867/java-type-inference-with-lower-bounded-types
>
> Does anyone on the list have insight into why the compiler does not 
> infer lower bounded types?
>
> static class Test {
>     static <T> T pick(T one, T two) {
>         return two;
>     }
>
>     static void testUpperBound() {
>         List<? extends Integer> extendsInteger = new ArrayList<>();
>
>         // List<? extends Integer> is treated as a subclass of List<? 
> extends Number>
>         List<? extends Number> extendsNumber = extendsInteger;
>
>         // List<? extends Number> is inferred as the common superclass
>         extendsNumber = pick(extendsInteger, extendsNumber);
>     }
>
>     static void testLowerBound() {
>         List<? super Number> superNumber = new ArrayList<>();
>
>         // List<? super Number> is treated as a subclass of List<? 
> super Integer>
>         List<? super Integer> superInteger = superNumber;
>
>         // The inferred common type should be List<? super Integer>,
>         // but instead we get a compile error:
> *superInteger = pick(superNumber, superInteger);*
>
>         // It only compiles with an explicit type argument:
>         superInteger = Test.<List<? super Integer>>pick(superNumber, 
> superInteger);
>     }
> }
>
>
> Thanks
>
> --
> Sam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150103/901f0746/attachment-0001.html>

From jonathan.gibbons at oracle.com  Mon Jan  5 18:29:29 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Jan 2015 10:29:29 -0800
Subject: [PATCH] Pretty printing for loops
In-Reply-To: <20141205084557.GC13527@faui20e.informatik.uni-erlangen.de>
References: <20141205084557.GC13527@faui20e.informatik.uni-erlangen.de>
Message-ID: <54AAD809.4050605@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8068460

On 12/05/2014 12:45 AM, Tobias Werth wrote:
> Hi,
>
> (if this is not the correct mailing list to submit those patches, please
> tell me which one to use instead)
>
> I stumbled upon a bug in the javac pretty printer. It misses a null
> check while pretty printing for loops causing to produce invalid code.
>
> The attached patch contains a fix including a test that fails before and
> works after applying the patch.
>
> Cheers,
> Tobi
>


From jonathan.gibbons at oracle.com  Mon Jan  5 18:59:57 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 05 Jan 2015 10:59:57 -0800
Subject: [PATCH] Pretty printing for loops
In-Reply-To: <20141205084557.GC13527@faui20e.informatik.uni-erlangen.de>
References: <20141205084557.GC13527@faui20e.informatik.uni-erlangen.de>
Message-ID: <54AADF2D.8010608@oracle.com>


On 12/05/2014 12:45 AM, Tobias Werth wrote:
> Hi,
>
> (if this is not the correct mailing list to submit those patches, please
> tell me which one to use instead)
>
> I stumbled upon a bug in the javac pretty printer. It misses a null
> check while pretty printing for loops causing to produce invalid code.
>
> The attached patch contains a fix including a test that fails before and
> works after applying the patch.
>
> Cheers,
> Tobi
>

Tobi,

Thank you for your patch. In reviewing the code, I note that the test 
will probably fail on Windows, because of the "newline issue".
javac Pretty will render the source code using platform newlines, which 
means the assertEquals on line 73 will fail.

The general recommendation in cases like this is to do something like:

-  81         return sw.toString();
+             String NL = System.getProperty("line.separator");
+  81         return sw.replace(NL, "\n").toString();
  

-- Jon

From daniel.smith at oracle.com  Tue Jan  6 20:06:42 2015
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 6 Jan 2015 13:06:42 -0700
Subject: Generic ype inference with lower bounded types
In-Reply-To: <54A73AA9.5010603@oracle.com>
References: <CABjcb6VRM8xoyUeS_TeBQX-V+_Hqws_=7ia6QtyGrBWtMw0j+w@mail.gmail.com>
	<54A73AA9.5010603@oracle.com>
Message-ID: <5771A8AC-B225-4890-A980-21B09ECD24F2@oracle.com>

TLDR: this is a known limitation, tracked here:
https://bugs.openjdk.java.net/browse/JDK-5052943

To be concrete, the problem is in the definition of the "least upper bound (lub)" function:

http://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10.4

JLS 8 happens to sidestep the issue by using more contextual information during inference, avoiding the need to use lub, but you can still get the same problem with some tweaking of the test.

Type inference is trying to find a common supertype of the two arguments, superNumber and superInteger.  So it calls lub.  lub knows the answer is List<[something]>, and tries to find a wildcard to fill in [something].

You might think this rule would apply:
lcta(? super U, ? super V) = ? super glb(U, V)

Concretely, that would be:
lcta(? super Number, ? super Integer) = ? super Integer

But those aren't actually the types involved.  The reference to 'superNumber' has type List<CAP1> where CAP1 has lower bound Number (see JLS 6.5.6.1).  Similarly, 'superInteger' has type List<CAP2> where CAP2 has lower bound Integer.

So we end up with this rule:
lcta(U, V) = U if U = V, otherwise ? extends lub(U, V)

That is,
lcta(CAP1, CAP2) = ? extends lub(CAP1, CAP2) = ? extends Object

So inference decides T=List<? extends Object>.

There's not a fundamental reason we can't do better; JDK-5052943 is being used to track any changes.

?Dan

> On Jan 2, 2015, at 5:41 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi Sam,
> This works in JDK 8 (I think there's even a comment in SO saying that). Long story short, Java 5/6/7 inference typically ignored inference constraints coming from lower bounds; the treatment in Java 8 is much more consistent - as a result this program compiles as you'd expect (assuming you don't use -source 7).
> 
> Maurizio
> 
> On 03/01/15 00:07, Sam Munkes wrote:
>> Hi Guys,
>> 
>> A colleague of mine recently posted the following question to StackOverflow: http://stackoverflow.com/questions/27652867/java-type-inference-with-lower-bounded-types
>> 
>> Does anyone on the list have insight into why the compiler does not infer lower bounded types?
>> 
>> static class Test {
>>     static <T> T pick(T one, T two) {
>>         return two;
>>     }
>> 
>>     static void testUpperBound() {
>>         List<? extends Integer> extendsInteger = new ArrayList<>();
>> 
>>         // List<? extends Integer> is treated as a subclass of List<? extends Number>
>>         List<? extends Number> extendsNumber = extendsInteger;
>> 
>>         // List<? extends Number> is inferred as the common superclass
>>         extendsNumber = pick(extendsInteger, extendsNumber);
>>     }
>> 
>>     static void testLowerBound() {
>>         List<? super Number> superNumber = new ArrayList<>();
>> 
>>         // List<? super Number> is treated as a subclass of List<? super Integer>
>>         List<? super Integer> superInteger = superNumber;
>> 
>>         // The inferred common type should be List<? super Integer>,
>>         // but instead we get a compile error:
>>         superInteger = pick(superNumber, superInteger);
>> 
>>         // It only compiles with an explicit type argument:
>>         superInteger = Test.<List<? super Integer>>pick(superNumber, superInteger);
>>     }
>> }
>> 
>> 
>> Thanks
>> 
>> --
>> Sam
> 


From twalthr at apache.org  Wed Jan  7 15:22:12 2015
From: twalthr at apache.org (Timo Walther)
Date: Wed, 07 Jan 2015 16:22:12 +0100
Subject: Introduce a compiler option to store generic type information about
	a lambda expression using the Signature Attribute
Message-ID: <54AD4F24.2080605@apache.org>

Hi all,

the Java Reflection API allows to access the generic signature of 
methods through the java.lang.reflect.Method#getGenericReturnType() 
method. However, this is not yet supported for Lambda expressions.

Given the following classes:

class Tuple2<F0,F1> {
   F0 field0;
   F1 field1;

   public Tuple2(F0 f0, F1 f1) {
     this.field0 = f0;
     this.field1 = f1;
   }
}

interface Map<IN, OUT> {
   OUT map(IN in);
}

Currently, there is no solution that allows to get further type 
information about expressions like:

Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
System.out.println(getReturnType(map)) // can only print Tuple2 => 
information about the Tuple2's fields are always lost

Especially data-intensive runtimes (like Apache Flink[0] where I am 
working on) need as much type information as possible to be efficient. 
Therefore, we searched for a way to also extract type information from 
lambda expressions. Adding a generic signature to the generated 
"lambda$XXX" static methods (at least by using a compiler option) would 
be the perfect solution. It seems that the JVM Specification does not 
prohibit such an implementation. An implementation of a later extraction 
is described here[1].

The Eclipse JDT compiler team is introducing a compiler option 
"-genericsignature" with version 4.5 M4[2].

I have implemented a patch prototype. It can be found at: 
http://people.apache.org/~twalthr/patches/lambdaSignature.patch

The patch postpones the type erasure of the lambda function's parameters 
after the generic descriptor has been saved in a newly introduced 
variable in MethodSymbol (if compiler option "-lambdasignature" is set). 
The contents of the variable is read in ClassWriter and written to 
method's Signature attribute in the classfile. Tests are also included.

No change to the class file format is required. The change is guarded by 
a compiler option, so without that addition, nothing should behave 
differently.


[0] http://flink.apache.org/
[1] 
http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063


Regards,
Timo Walther

From maurizio.cimadamore at oracle.com  Wed Jan  7 15:47:22 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 07 Jan 2015 15:47:22 +0000
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD4F24.2080605@apache.org>
References: <54AD4F24.2080605@apache.org>
Message-ID: <54AD550A.1050806@oracle.com>

Hi Timo,
thanks for the patch - if I'm not mistaken, this would be the very first 
case in which a method marked with ACC_SYNTHETIC also gets a signature 
attribute. I will consult with the rest of the team and see if there's 
any objection.

Cheers
Maurizio

On 07/01/15 15:22, Timo Walther wrote:
> Hi all,
>
> the Java Reflection API allows to access the generic signature of 
> methods through the java.lang.reflect.Method#getGenericReturnType() 
> method. However, this is not yet supported for Lambda expressions.
>
> Given the following classes:
>
> class Tuple2<F0,F1> {
>   F0 field0;
>   F1 field1;
>
>   public Tuple2(F0 f0, F1 f1) {
>     this.field0 = f0;
>     this.field1 = f1;
>   }
> }
>
> interface Map<IN, OUT> {
>   OUT map(IN in);
> }
>
> Currently, there is no solution that allows to get further type 
> information about expressions like:
>
> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
> System.out.println(getReturnType(map)) // can only print Tuple2 => 
> information about the Tuple2's fields are always lost
>
> Especially data-intensive runtimes (like Apache Flink[0] where I am 
> working on) need as much type information as possible to be efficient. 
> Therefore, we searched for a way to also extract type information from 
> lambda expressions. Adding a generic signature to the generated 
> "lambda$XXX" static methods (at least by using a compiler option) 
> would be the perfect solution. It seems that the JVM Specification 
> does not prohibit such an implementation. An implementation of a later 
> extraction is described here[1].
>
> The Eclipse JDT compiler team is introducing a compiler option 
> "-genericsignature" with version 4.5 M4[2].
>
> I have implemented a patch prototype. It can be found at: 
> http://people.apache.org/~twalthr/patches/lambdaSignature.patch
>
> The patch postpones the type erasure of the lambda function's 
> parameters after the generic descriptor has been saved in a newly 
> introduced variable in MethodSymbol (if compiler option 
> "-lambdasignature" is set). The contents of the variable is read in 
> ClassWriter and written to method's Signature attribute in the 
> classfile. Tests are also included.
>
> No change to the class file format is required. The change is guarded 
> by a compiler option, so without that addition, nothing should behave 
> differently.
>
>
> [0] http://flink.apache.org/
> [1] 
> http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063
>
>
> Regards,
> Timo Walther


From forax at univ-mlv.fr  Wed Jan  7 16:21:17 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 07 Jan 2015 17:21:17 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD550A.1050806@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD550A.1050806@oracle.com>
Message-ID: <54AD5CFD.9000405@univ-mlv.fr>

We (the lambda EG) discusses that issue last year,
as far as I remember, it was decided to not support generic signature in 
lambda proxy by default,
now I see no problem to make this information accessible through a flag.

cheers,
R?mi

On 01/07/2015 04:47 PM, Maurizio Cimadamore wrote:
> Hi Timo,
> thanks for the patch - if I'm not mistaken, this would be the very 
> first case in which a method marked with ACC_SYNTHETIC also gets a 
> signature attribute. I will consult with the rest of the team and see 
> if there's any objection.
>
> Cheers
> Maurizio
>
> On 07/01/15 15:22, Timo Walther wrote:
>> Hi all,
>>
>> the Java Reflection API allows to access the generic signature of 
>> methods through the java.lang.reflect.Method#getGenericReturnType() 
>> method. However, this is not yet supported for Lambda expressions.
>>
>> Given the following classes:
>>
>> class Tuple2<F0,F1> {
>>   F0 field0;
>>   F1 field1;
>>
>>   public Tuple2(F0 f0, F1 f1) {
>>     this.field0 = f0;
>>     this.field1 = f1;
>>   }
>> }
>>
>> interface Map<IN, OUT> {
>>   OUT map(IN in);
>> }
>>
>> Currently, there is no solution that allows to get further type 
>> information about expressions like:
>>
>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 
>> 1);
>> System.out.println(getReturnType(map)) // can only print Tuple2 => 
>> information about the Tuple2's fields are always lost
>>
>> Especially data-intensive runtimes (like Apache Flink[0] where I am 
>> working on) need as much type information as possible to be 
>> efficient. Therefore, we searched for a way to also extract type 
>> information from lambda expressions. Adding a generic signature to 
>> the generated "lambda$XXX" static methods (at least by using a 
>> compiler option) would be the perfect solution. It seems that the JVM 
>> Specification does not prohibit such an implementation. An 
>> implementation of a later extraction is described here[1].
>>
>> The Eclipse JDT compiler team is introducing a compiler option 
>> "-genericsignature" with version 4.5 M4[2].
>>
>> I have implemented a patch prototype. It can be found at: 
>> http://people.apache.org/~twalthr/patches/lambdaSignature.patch
>>
>> The patch postpones the type erasure of the lambda function's 
>> parameters after the generic descriptor has been saved in a newly 
>> introduced variable in MethodSymbol (if compiler option 
>> "-lambdasignature" is set). The contents of the variable is read in 
>> ClassWriter and written to method's Signature attribute in the 
>> classfile. Tests are also included.
>>
>> No change to the class file format is required. The change is guarded 
>> by a compiler option, so without that addition, nothing should behave 
>> differently.
>>
>>
>> [0] http://flink.apache.org/
>> [1] 
>> http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063
>>
>>
>> Regards,
>> Timo Walther
>


From maurizio.cimadamore at oracle.com  Wed Jan  7 16:31:08 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 07 Jan 2015 16:31:08 +0000
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD5CFD.9000405@univ-mlv.fr>
References: <54AD4F24.2080605@apache.org> <54AD550A.1050806@oracle.com>
	<54AD5CFD.9000405@univ-mlv.fr>
Message-ID: <54AD5F4C.40309@oracle.com>

One thing that worries me is that, while this would work generally well 
in simple cases, there will always be the bad corner case in which you 
need a bridge (generated dynamically by the lambda metafactory) and that 
bridge will not have the signature attribute (since it's not javac 
generated). Now, when we require bridging, lambda capture goes through 
the slow path (altMetafactory) - so maybe it's not too much of a concern 
if we added some logic there to regenerate the signature attribute on 
the bridge (although, I must note, not even ordinary javac bridges have 
signature attributes)...

Maurizio

On 07/01/15 16:21, Remi Forax wrote:
> We (the lambda EG) discusses that issue last year,
> as far as I remember, it was decided to not support generic signature 
> in lambda proxy by default,
> now I see no problem to make this information accessible through a flag.
>
> cheers,
> R?mi
>
> On 01/07/2015 04:47 PM, Maurizio Cimadamore wrote:
>> Hi Timo,
>> thanks for the patch - if I'm not mistaken, this would be the very 
>> first case in which a method marked with ACC_SYNTHETIC also gets a 
>> signature attribute. I will consult with the rest of the team and see 
>> if there's any objection.
>>
>> Cheers
>> Maurizio
>>
>> On 07/01/15 15:22, Timo Walther wrote:
>>> Hi all,
>>>
>>> the Java Reflection API allows to access the generic signature of 
>>> methods through the java.lang.reflect.Method#getGenericReturnType() 
>>> method. However, this is not yet supported for Lambda expressions.
>>>
>>> Given the following classes:
>>>
>>> class Tuple2<F0,F1> {
>>>   F0 field0;
>>>   F1 field1;
>>>
>>>   public Tuple2(F0 f0, F1 f1) {
>>>     this.field0 = f0;
>>>     this.field1 = f1;
>>>   }
>>> }
>>>
>>> interface Map<IN, OUT> {
>>>   OUT map(IN in);
>>> }
>>>
>>> Currently, there is no solution that allows to get further type 
>>> information about expressions like:
>>>
>>> Map<String, Tuple2<String, Integer>> map = (str) -> new 
>>> Tuple2<>(str, 1);
>>> System.out.println(getReturnType(map)) // can only print Tuple2 => 
>>> information about the Tuple2's fields are always lost
>>>
>>> Especially data-intensive runtimes (like Apache Flink[0] where I am 
>>> working on) need as much type information as possible to be 
>>> efficient. Therefore, we searched for a way to also extract type 
>>> information from lambda expressions. Adding a generic signature to 
>>> the generated "lambda$XXX" static methods (at least by using a 
>>> compiler option) would be the perfect solution. It seems that the 
>>> JVM Specification does not prohibit such an implementation. An 
>>> implementation of a later extraction is described here[1].
>>>
>>> The Eclipse JDT compiler team is introducing a compiler option 
>>> "-genericsignature" with version 4.5 M4[2].
>>>
>>> I have implemented a patch prototype. It can be found at: 
>>> http://people.apache.org/~twalthr/patches/lambdaSignature.patch
>>>
>>> The patch postpones the type erasure of the lambda function's 
>>> parameters after the generic descriptor has been saved in a newly 
>>> introduced variable in MethodSymbol (if compiler option 
>>> "-lambdasignature" is set). The contents of the variable is read in 
>>> ClassWriter and written to method's Signature attribute in the 
>>> classfile. Tests are also included.
>>>
>>> No change to the class file format is required. The change is 
>>> guarded by a compiler option, so without that addition, nothing 
>>> should behave differently.
>>>
>>>
>>> [0] http://flink.apache.org/
>>> [1] 
>>> http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas
>>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063
>>>
>>>
>>> Regards,
>>> Timo Walther
>>
>


From forax at univ-mlv.fr  Wed Jan  7 16:42:08 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 07 Jan 2015 17:42:08 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD5F4C.40309@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD550A.1050806@oracle.com>
	<54AD5CFD.9000405@univ-mlv.fr> <54AD5F4C.40309@oracle.com>
Message-ID: <54AD61E0.90802@univ-mlv.fr>

Yes,
following the same idea,
we can restrict the generation of metadata either from javac or from the 
metafactory
to serializable lambda because it already requires a bunch of metadata.

R?mi

On 01/07/2015 05:31 PM, Maurizio Cimadamore wrote:
> One thing that worries me is that, while this would work generally 
> well in simple cases, there will always be the bad corner case in 
> which you need a bridge (generated dynamically by the lambda 
> metafactory) and that bridge will not have the signature attribute 
> (since it's not javac generated). Now, when we require bridging, 
> lambda capture goes through the slow path (altMetafactory) - so maybe 
> it's not too much of a concern if we added some logic there to 
> regenerate the signature attribute on the bridge (although, I must 
> note, not even ordinary javac bridges have signature attributes)...
>
> Maurizio
>
> On 07/01/15 16:21, Remi Forax wrote:
>> We (the lambda EG) discusses that issue last year,
>> as far as I remember, it was decided to not support generic signature 
>> in lambda proxy by default,
>> now I see no problem to make this information accessible through a flag.
>>
>> cheers,
>> R?mi
>>
>> On 01/07/2015 04:47 PM, Maurizio Cimadamore wrote:
>>> Hi Timo,
>>> thanks for the patch - if I'm not mistaken, this would be the very 
>>> first case in which a method marked with ACC_SYNTHETIC also gets a 
>>> signature attribute. I will consult with the rest of the team and 
>>> see if there's any objection.
>>>
>>> Cheers
>>> Maurizio
>>>
>>> On 07/01/15 15:22, Timo Walther wrote:
>>>> Hi all,
>>>>
>>>> the Java Reflection API allows to access the generic signature of 
>>>> methods through the java.lang.reflect.Method#getGenericReturnType() 
>>>> method. However, this is not yet supported for Lambda expressions.
>>>>
>>>> Given the following classes:
>>>>
>>>> class Tuple2<F0,F1> {
>>>>   F0 field0;
>>>>   F1 field1;
>>>>
>>>>   public Tuple2(F0 f0, F1 f1) {
>>>>     this.field0 = f0;
>>>>     this.field1 = f1;
>>>>   }
>>>> }
>>>>
>>>> interface Map<IN, OUT> {
>>>>   OUT map(IN in);
>>>> }
>>>>
>>>> Currently, there is no solution that allows to get further type 
>>>> information about expressions like:
>>>>
>>>> Map<String, Tuple2<String, Integer>> map = (str) -> new 
>>>> Tuple2<>(str, 1);
>>>> System.out.println(getReturnType(map)) // can only print Tuple2 => 
>>>> information about the Tuple2's fields are always lost
>>>>
>>>> Especially data-intensive runtimes (like Apache Flink[0] where I am 
>>>> working on) need as much type information as possible to be 
>>>> efficient. Therefore, we searched for a way to also extract type 
>>>> information from lambda expressions. Adding a generic signature to 
>>>> the generated "lambda$XXX" static methods (at least by using a 
>>>> compiler option) would be the perfect solution. It seems that the 
>>>> JVM Specification does not prohibit such an implementation. An 
>>>> implementation of a later extraction is described here[1].
>>>>
>>>> The Eclipse JDT compiler team is introducing a compiler option 
>>>> "-genericsignature" with version 4.5 M4[2].
>>>>
>>>> I have implemented a patch prototype. It can be found at: 
>>>> http://people.apache.org/~twalthr/patches/lambdaSignature.patch
>>>>
>>>> The patch postpones the type erasure of the lambda function's 
>>>> parameters after the generic descriptor has been saved in a newly 
>>>> introduced variable in MethodSymbol (if compiler option 
>>>> "-lambdasignature" is set). The contents of the variable is read in 
>>>> ClassWriter and written to method's Signature attribute in the 
>>>> classfile. Tests are also included.
>>>>
>>>> No change to the class file format is required. The change is 
>>>> guarded by a compiler option, so without that addition, nothing 
>>>> should behave differently.
>>>>
>>>>
>>>> [0] http://flink.apache.org/
>>>> [1] 
>>>> http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas
>>>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063
>>>>
>>>>
>>>> Regards,
>>>> Timo Walther
>>>
>>
>


From alex.buckley at oracle.com  Wed Jan  7 20:18:43 2015
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 07 Jan 2015 12:18:43 -0800
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD4F24.2080605@apache.org>
References: <54AD4F24.2080605@apache.org>
Message-ID: <54AD94A3.9050907@oracle.com>

On 1/7/2015 7:22 AM, Timo Walther wrote:
> the Java Reflection API allows to access the generic signature of
> methods through the java.lang.reflect.Method#getGenericReturnType()
> method. However, this is not yet supported for Lambda expressions.
>
> Given the following classes:
>
> class Tuple2<F0,F1> {
>    F0 field0;
>    F1 field1;
>
>    public Tuple2(F0 f0, F1 f1) {
>      this.field0 = f0;
>      this.field1 = f1;
>    }
> }
>
> interface Map<IN, OUT> {
>    OUT map(IN in);
> }
>
> Currently, there is no solution that allows to get further type
> information about expressions like:
>
> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
> System.out.println(getReturnType(map)) // can only print Tuple2 =>
> information about the Tuple2's fields are always lost

map is a variable, so it doesn't have a return type.

If map is a class variable or an instance variable, then 
Field#getGenericType should help.

Expressions (including lambda expressions) aren't generally exposed 
through Core Reflection. If an expression (such as a lambda expression) 
happens to be implemented as a method, then relying on the [generic] 
signature of that method is dangerous since it may change from release 
to release.

Alex

From joe.darcy at oracle.com  Thu Jan  8 00:47:33 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 07 Jan 2015 16:47:33 -0800
Subject: JDK 9 RFR of 8068639 : Make certain annotation classfile warnings
	opt-in
Message-ID: <54ADD3A5.9080409@oracle.com>

Hello,

Our EE associates have reported some issues transitioning EE to use 
repeating annotations, certain desirable compilation setups lead to 
discouraging warnings.

Please review this small change to ease the EE migration snag:

     JDK-8068639 : Make certain annotation classfile warnings opt-in
     http://cr.openjdk.java.net/~darcy/8068639.0/

Patch below.

The intention is to backport this change to the 8u and 7u trains as well.

Thanks,

-Joe

--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java 
2015-01-07 16:07:58.958480591 -0800
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java 
2015-01-07 16:07:58.870480591 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -1740,15 +1740,17 @@
              // The method wasn't found: emit a warning and recover
              JavaFileObject prevSource = 
log.useSource(requestingOwner.classfile);
              try {
-                if (failure == null) {
-                    log.warning("annotation.method.not.found",
-                                container,
-                                name);
-                } else {
- log.warning("annotation.method.not.found.reason",
-                                container,
-                                name,
- failure.getDetailValue());//diagnostic, if present
+                if (lintClassfile) {
+                    if (failure == null) {
+                        log.warning("annotation.method.not.found",
+                                    container,
+                                    name);
+                    } else {
+ log.warning("annotation.method.not.found.reason",
+                                    container,
+                                    name,
+ failure.getDetailValue());//diagnostic, if present
+                    }
                  }
              } finally {
                  log.useSource(prevSource);
--- old/test/tools/javac/annotations/6214965/T6214965.java 2015-01-07 
16:07:59.322480591 -0800
+++ new/test/tools/javac/annotations/6214965/T6214965.java 2015-01-07 
16:07:59.234480591 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -27,5 +27,5 @@
   * @summary Compiler crash on redefing nested annotation types
   * @compile CompilerAnnotationTest.java CompilerAnnotationTest2.java
   * @compile CompilerAnnotationTest2bad.java
- * @compile/ref=T6214965.out -XDrawDiagnostics 
CompilerAnnotationTest2bad.java
+ * @compile/ref=T6214965.out -XDrawDiagnostics -Xlint:classfile 
CompilerAnnotationTest2bad.java
   */
--- old/test/tools/javac/annotations/6365854/T6365854.java 2015-01-07 
16:07:59.638480591 -0800
+++ new/test/tools/javac/annotations/6365854/T6365854.java 2015-01-07 
16:07:59.546480591 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -33,11 +33,11 @@
   *
   * @compile TestAnnotation.java TestCore.java
   * @clean test.annotation.TestAnnotation
- * @compile/ref=test1.out -XDrawDiagnostics T6365854.java
+ * @compile/ref=test1.out -XDrawDiagnostics -Xlint:classfile T6365854.java
   * @run main T6365854
- * @compile/ref=test2.out -XDrawDiagnostics evolve/TestAnnotation.java 
T6365854.java
+ * @compile/ref=test2.out -XDrawDiagnostics -Xlint:classfile 
evolve/TestAnnotation.java T6365854.java
   * @run main T6365854
- * @compile/ref=test2.out -XDrawDiagnostics T6365854.java
+ * @compile/ref=test2.out -XDrawDiagnostics -Xlint:classfile T6365854.java
   * @run main T6365854
   */



From jonathan.gibbons at oracle.com  Thu Jan  8 01:16:08 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 07 Jan 2015 17:16:08 -0800
Subject: JDK 9 RFR of 8068639 : Make certain annotation classfile warnings
	opt-in
In-Reply-To: <54ADD3A5.9080409@oracle.com>
References: <54ADD3A5.9080409@oracle.com>
Message-ID: <54ADDA58.7050706@oracle.com>

Joe,

Looks good, but it would be even better to make sure the warnings are 
not generated if the lint option is not given, as in:

- * @compile/ref=T6214965.out -XDrawDiagnostics 
CompilerAnnotationTest2bad.java
+ * @compile/ref=T6214965.out -XDrawDiagnostics -Xlint:classfile 
CompilerAnnotationTest2bad.java
+ * @compile -Werror CompilerAnnotationTest2bad.java

-- Jon

On 01/07/2015 04:47 PM, joe darcy wrote:
> Hello,
>
> Our EE associates have reported some issues transitioning EE to use 
> repeating annotations, certain desirable compilation setups lead to 
> discouraging warnings.
>
> Please review this small change to ease the EE migration snag:
>
>     JDK-8068639 : Make certain annotation classfile warnings opt-in
>     http://cr.openjdk.java.net/~darcy/8068639.0/
>
> Patch below.
>
> The intention is to backport this change to the 8u and 7u trains as well.
>
> Thanks,
>
> -Joe
>
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java 
> 2015-01-07 16:07:58.958480591 -0800
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java 
> 2015-01-07 16:07:58.870480591 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -1740,15 +1740,17 @@
>              // The method wasn't found: emit a warning and recover
>              JavaFileObject prevSource = 
> log.useSource(requestingOwner.classfile);
>              try {
> -                if (failure == null) {
> -                    log.warning("annotation.method.not.found",
> -                                container,
> -                                name);
> -                } else {
> - log.warning("annotation.method.not.found.reason",
> -                                container,
> -                                name,
> - failure.getDetailValue());//diagnostic, if present
> +                if (lintClassfile) {
> +                    if (failure == null) {
> + log.warning("annotation.method.not.found",
> +                                    container,
> +                                    name);
> +                    } else {
> + log.warning("annotation.method.not.found.reason",
> +                                    container,
> +                                    name,
> + failure.getDetailValue());//diagnostic, if present
> +                    }
>                  }
>              } finally {
>                  log.useSource(prevSource);
> --- old/test/tools/javac/annotations/6214965/T6214965.java 2015-01-07 
> 16:07:59.322480591 -0800
> +++ new/test/tools/javac/annotations/6214965/T6214965.java 2015-01-07 
> 16:07:59.234480591 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -27,5 +27,5 @@
>   * @summary Compiler crash on redefing nested annotation types
>   * @compile CompilerAnnotationTest.java CompilerAnnotationTest2.java
>   * @compile CompilerAnnotationTest2bad.java
> - * @compile/ref=T6214965.out -XDrawDiagnostics 
> CompilerAnnotationTest2bad.java
> + * @compile/ref=T6214965.out -XDrawDiagnostics -Xlint:classfile 
> CompilerAnnotationTest2bad.java
>   */
> --- old/test/tools/javac/annotations/6365854/T6365854.java 2015-01-07 
> 16:07:59.638480591 -0800
> +++ new/test/tools/javac/annotations/6365854/T6365854.java 2015-01-07 
> 16:07:59.546480591 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -33,11 +33,11 @@
>   *
>   * @compile TestAnnotation.java TestCore.java
>   * @clean test.annotation.TestAnnotation
> - * @compile/ref=test1.out -XDrawDiagnostics T6365854.java
> + * @compile/ref=test1.out -XDrawDiagnostics -Xlint:classfile 
> T6365854.java
>   * @run main T6365854
> - * @compile/ref=test2.out -XDrawDiagnostics 
> evolve/TestAnnotation.java T6365854.java
> + * @compile/ref=test2.out -XDrawDiagnostics -Xlint:classfile 
> evolve/TestAnnotation.java T6365854.java
>   * @run main T6365854
> - * @compile/ref=test2.out -XDrawDiagnostics T6365854.java
> + * @compile/ref=test2.out -XDrawDiagnostics -Xlint:classfile 
> T6365854.java
>   * @run main T6365854
>   */
>
>


From joe.darcy at oracle.com  Thu Jan  8 01:27:13 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 07 Jan 2015 17:27:13 -0800
Subject: JDK 9 RFR of 8068639 : Make certain annotation classfile warnings
	opt-in
In-Reply-To: <54ADDA58.7050706@oracle.com>
References: <54ADD3A5.9080409@oracle.com> <54ADDA58.7050706@oracle.com>
Message-ID: <54ADDCF1.3020201@oracle.com>

Jon,

On 1/7/2015 5:16 PM, Jonathan Gibbons wrote:
> Joe,
>
> Looks good, but it would be even better to make sure the warnings are 
> not generated if the lint option is not given, as in:
>
> - * @compile/ref=T6214965.out -XDrawDiagnostics 
> CompilerAnnotationTest2bad.java
> + * @compile/ref=T6214965.out -XDrawDiagnostics -Xlint:classfile 
> CompilerAnnotationTest2bad.java
> + * @compile -Werror CompilerAnnotationTest2bad.java

Good point; I've make that change and also added "8068639" to the @bug 
line of both updated tests:

     http://cr.openjdk.java.net/~darcy/8068639.1

Thanks,

-Joe

>
> -- Jon
>
> On 01/07/2015 04:47 PM, joe darcy wrote:
>> Hello,
>>
>> Our EE associates have reported some issues transitioning EE to use 
>> repeating annotations, certain desirable compilation setups lead to 
>> discouraging warnings.
>>
>> Please review this small change to ease the EE migration snag:
>>
>>     JDK-8068639 : Make certain annotation classfile warnings opt-in
>>     http://cr.openjdk.java.net/~darcy/8068639.0/
>>
>> Patch below.
>>
>> The intention is to backport this change to the 8u and 7u trains as 
>> well.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- 
>> old/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java 
>> 2015-01-07 16:07:58.958480591 -0800
>> +++ 
>> new/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java 
>> 2015-01-07 16:07:58.870480591 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -1740,15 +1740,17 @@
>>              // The method wasn't found: emit a warning and recover
>>              JavaFileObject prevSource = 
>> log.useSource(requestingOwner.classfile);
>>              try {
>> -                if (failure == null) {
>> -                    log.warning("annotation.method.not.found",
>> -                                container,
>> -                                name);
>> -                } else {
>> - log.warning("annotation.method.not.found.reason",
>> -                                container,
>> -                                name,
>> - failure.getDetailValue());//diagnostic, if present
>> +                if (lintClassfile) {
>> +                    if (failure == null) {
>> + log.warning("annotation.method.not.found",
>> +                                    container,
>> +                                    name);
>> +                    } else {
>> + log.warning("annotation.method.not.found.reason",
>> +                                    container,
>> +                                    name,
>> + failure.getDetailValue());//diagnostic, if present
>> +                    }
>>                  }
>>              } finally {
>>                  log.useSource(prevSource);
>> --- old/test/tools/javac/annotations/6214965/T6214965.java 2015-01-07 
>> 16:07:59.322480591 -0800
>> +++ new/test/tools/javac/annotations/6214965/T6214965.java 2015-01-07 
>> 16:07:59.234480591 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -27,5 +27,5 @@
>>   * @summary Compiler crash on redefing nested annotation types
>>   * @compile CompilerAnnotationTest.java CompilerAnnotationTest2.java
>>   * @compile CompilerAnnotationTest2bad.java
>> - * @compile/ref=T6214965.out -XDrawDiagnostics 
>> CompilerAnnotationTest2bad.java
>> + * @compile/ref=T6214965.out -XDrawDiagnostics -Xlint:classfile 
>> CompilerAnnotationTest2bad.java
>>   */
>> --- old/test/tools/javac/annotations/6365854/T6365854.java 2015-01-07 
>> 16:07:59.638480591 -0800
>> +++ new/test/tools/javac/annotations/6365854/T6365854.java 2015-01-07 
>> 16:07:59.546480591 -0800
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2005, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -33,11 +33,11 @@
>>   *
>>   * @compile TestAnnotation.java TestCore.java
>>   * @clean test.annotation.TestAnnotation
>> - * @compile/ref=test1.out -XDrawDiagnostics T6365854.java
>> + * @compile/ref=test1.out -XDrawDiagnostics -Xlint:classfile 
>> T6365854.java
>>   * @run main T6365854
>> - * @compile/ref=test2.out -XDrawDiagnostics 
>> evolve/TestAnnotation.java T6365854.java
>> + * @compile/ref=test2.out -XDrawDiagnostics -Xlint:classfile 
>> evolve/TestAnnotation.java T6365854.java
>>   * @run main T6365854
>> - * @compile/ref=test2.out -XDrawDiagnostics T6365854.java
>> + * @compile/ref=test2.out -XDrawDiagnostics -Xlint:classfile 
>> T6365854.java
>>   * @run main T6365854
>>   */
>>
>>
>


From mark.reinhold at oracle.com  Thu Jan  8 22:20:36 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  8 Jan 2015 14:20:36 -0800 (PST)
Subject: JEP 235: Test Class-File Attributes Generated by javac
Message-ID: <20150108222036.C1FF048D8A@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/235

- Mark

From martijnverburg at gmail.com  Thu Jan  8 22:28:48 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 8 Jan 2015 22:28:48 +0000
Subject: JEP 235: Test Class-File Attributes Generated by javac
In-Reply-To: <20150108222036.C1FF048D8A@eggemoggin.niobe.net>
References: <20150108222036.C1FF048D8A@eggemoggin.niobe.net>
Message-ID: <CAP7YuAR3cQnQ40yff-58L6VcLLgvQfPCoafv2Zhh+HsaH8WcuA@mail.gmail.com>

Hi all,

Just wanted to say that it's really heartening to see JEPs like this get
added.  It's not glamorous, and most developers will never notice it, but
it's this sort of extra robustness that really makes Java the reliable
platform that so many people rely on day after day. So from this Java user
- thank you.

Cheers,
Martijn

On 8 January 2015 at 22:20, <mark.reinhold at oracle.com> wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/235
>
> - Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150108/a36861e6/attachment.html>

From twalthr at apache.org  Fri Jan  9 13:27:08 2015
From: twalthr at apache.org (Timo Walther)
Date: Fri, 09 Jan 2015 14:27:08 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD94A3.9050907@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
Message-ID: <54AFD72C.6000505@apache.org>

Yes, you are right. It can be dangerous if not implemented safely and it 
is a pretty hacky solution, we are aware of that.

However, in Flink we stick to the paradigm "Write like a programming 
language, execute like a database", the more type information we have 
the efficient the program can be execute.
But this is quite difficult if type information is missing.

In programs like

stringData
.flatMap((String s, Collector<String> out) -> out.collect(s) )
.writeToFile("xyz");

we have currently no chance to determine the type of the collector after 
erasure and have to treat it as "Object". This makes Lambda expression 
inefficient in many use cases.

Other hacks that use e.g. the constant pool 
(https://github.com/jhalterman/typetools) do also not support generic 
lambda arguments.

So a compiler option would make many people happy.

Regards,
Timo

On 07.01.2015 21:18, Alex Buckley wrote:
> On 1/7/2015 7:22 AM, Timo Walther wrote:
>> the Java Reflection API allows to access the generic signature of
>> methods through the java.lang.reflect.Method#getGenericReturnType()
>> method. However, this is not yet supported for Lambda expressions.
>>
>> Given the following classes:
>>
>> class Tuple2<F0,F1> {
>>    F0 field0;
>>    F1 field1;
>>
>>    public Tuple2(F0 f0, F1 f1) {
>>      this.field0 = f0;
>>      this.field1 = f1;
>>    }
>> }
>>
>> interface Map<IN, OUT> {
>>    OUT map(IN in);
>> }
>>
>> Currently, there is no solution that allows to get further type
>> information about expressions like:
>>
>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 
>> 1);
>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>> information about the Tuple2's fields are always lost
>
> map is a variable, so it doesn't have a return type.
>
> If map is a class variable or an instance variable, then 
> Field#getGenericType should help.
>
> Expressions (including lambda expressions) aren't generally exposed 
> through Core Reflection. If an expression (such as a lambda 
> expression) happens to be implemented as a method, then relying on the 
> [generic] signature of that method is dangerous since it may change 
> from release to release.
>
> Alex


From sewen at apache.org  Fri Jan  9 13:58:04 2015
From: sewen at apache.org (Stephan Ewen)
Date: Fri, 9 Jan 2015 14:58:04 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AFD72C.6000505@apache.org>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
	<54AFD72C.6000505@apache.org>
Message-ID: <CANC1h_t=MHTV9qJGsLcf638ezEc5yD5+wuJzMmJu9PzO9qrCdQ@mail.gmail.com>

I can add to that as a committer in the same project as Timo (Apache Flink):

We can fall back to other generic means in the case where we do not get
this generic type information. If we have that type information, we can
configure and code-generate custom tailored type utilities, which make
things much more efficient..

In addition, it makes things more convenient for the users of Apache Flink.
They currently have (in some cases) to hint generic types that were type
erased.

Regards,
Stephan


On Fri, Jan 9, 2015 at 2:27 PM, Timo Walther <twalthr at apache.org> wrote:

> Yes, you are right. It can be dangerous if not implemented safely and it
> is a pretty hacky solution, we are aware of that.
>
> However, in Flink we stick to the paradigm "Write like a programming
> language, execute like a database", the more type information we have the
> efficient the program can be execute.
> But this is quite difficult if type information is missing.
>
> In programs like
>
> stringData
> .flatMap((String s, Collector<String> out) -> out.collect(s) )
> .writeToFile("xyz");
>
> we have currently no chance to determine the type of the collector after
> erasure and have to treat it as "Object". This makes Lambda expression
> inefficient in many use cases.
>
> Other hacks that use e.g. the constant pool (https://github.com/
> jhalterman/typetools) do also not support generic lambda arguments.
>
> So a compiler option would make many people happy.
>
> Regards,
> Timo
>
>
> On 07.01.2015 21:18, Alex Buckley wrote:
>
>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>
>>> the Java Reflection API allows to access the generic signature of
>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>> method. However, this is not yet supported for Lambda expressions.
>>>
>>> Given the following classes:
>>>
>>> class Tuple2<F0,F1> {
>>>    F0 field0;
>>>    F1 field1;
>>>
>>>    public Tuple2(F0 f0, F1 f1) {
>>>      this.field0 = f0;
>>>      this.field1 = f1;
>>>    }
>>> }
>>>
>>> interface Map<IN, OUT> {
>>>    OUT map(IN in);
>>> }
>>>
>>> Currently, there is no solution that allows to get further type
>>> information about expressions like:
>>>
>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>> information about the Tuple2's fields are always lost
>>>
>>
>> map is a variable, so it doesn't have a return type.
>>
>> If map is a class variable or an instance variable, then
>> Field#getGenericType should help.
>>
>> Expressions (including lambda expressions) aren't generally exposed
>> through Core Reflection. If an expression (such as a lambda expression)
>> happens to be implemented as a method, then relying on the [generic]
>> signature of that method is dangerous since it may change from release to
>> release.
>>
>> Alex
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150109/af13f36f/attachment.html>

From ron at paralleluniverse.co  Fri Jan  9 17:12:42 2015
From: ron at paralleluniverse.co (Ron Pressler)
Date: Fri, 9 Jan 2015 19:12:42 +0200
Subject: A few suggestions for small language changes
Message-ID: <CAAsnhpBwht-ryHVsigC_S2_GsfAHsNei9QmPCnPv8UPrUEk+6w@mail.gmail.com>

Hi everyone!

In the spirit of Java 7's project Coin, I'd like to propose four small
changes to the Java language. They require no new keywords or symbols, and
are fully backwards compatible. More importantly, they add no complexity --
in fact, they remove it, as a new Java programmer might expect the language
to behave in this way, and be surprised that it doesn't. None of the
proposed changes relies on any other.

1. Local declarations in conditionals and expressions:

    if ((int a = foo()) > 0 && (String b = bar()) != null)
        return b + a;

(vs:
    int a = foo();
    if (a > 0) {
        String b = bar();
        if (b != null)
           return b + a;
    }

or:
    int a;
    String b;
    if ((a = foo()) > 0 && (b = bar()) != null)
        return b + a;
)

and:

    return (int a = foo()) > 0 && (String b = bar()) != null ? b + a : "";

The scope of the variables is the expression or the if/while block.
This change will reduce nesting and LOC, or eliminate empty declarations
that are removed from initializations, and will reduce scope pollution.
This change will make Doug Lea's code shorter and a bit easier to follow :)


2. Allow no return from Void method:

    @Override
    Void foo() {
        System.out.println("done");
    }

This makes Void behave more like void.

3. Allow returning void (and use in expressions):

    @Override
    Void foo() {
        return System.out.println("done");
    }

but also:

    void foo() {
        return System.out.println("done");
    }

and:

    return a > b ? System.out.println("X") : System.exit(0);

This makes void behave more like Void ("void autoboxing")

4. Smart auto-casting:

    Object x = foo();
    if (x instanceof String)
        return x.length();

Obviously, this reduces a lot of tedious casts that the compiler can do on
its own. This is a more significant change, and there's the question of
handling conjunction and disjunction (or nesting) of instanceof tests.

This can also be taken further to introduce some sort of a switch over the
runtime type of a variable (a poor man's pattern matching), but that would
require new syntax.


Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150109/8930aadc/attachment.html>

From cushon at google.com  Fri Jan  9 18:14:11 2015
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 9 Jan 2015 10:14:11 -0800
Subject: javac9 and lower bounded wildcards
Message-ID: <CAL4Qsgu=SBtJV4UUT8AOwbWXH97-GWM-LJUUUoKWHqojvuVKvg@mail.gmail.com>

This is a bug, right? It reproduces with javac9-dev at head, and might be
related to JDK-8067858.

===
import java.util.*;

abstract class Test {
  abstract <T> void f(Collection<? super T> i);
  abstract <T> void f(List<? super T> i);

  <T> void m(List<T> a) {
    f(a);
  }
}
===

Test.java:8: error: reference to f is ambiguous
    f(a);
    ^
  both method <T#1>f(Collection<? super T#1>) in Test and method
<T#2>f(List<? super T#2>) in Test match
  where T#1,T#2 are type-variables:
    T#1 extends Object declared in method <T#1>f(Collection<? super T#1>)
    T#2 extends Object declared in method <T#2>f(List<? super T#2>)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150109/4c6925d7/attachment-0001.html>

From joe.darcy at oracle.com  Sat Jan 10 18:09:58 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Sat, 10 Jan 2015 10:09:58 -0800
Subject: JDK 9 RFR of JDK-8006469:Cleanup reflective access of
	java.lang.annotation.Repeatable
Message-ID: <54B16AF6.5070804@oracle.com>

Hello,

With JDK 9 now bootstrapping off of JDK 8, please review this fix to 
simplify access to the Repeatable annotation within javac; reflective 
access can be replaced with direct access:

     http://cr.openjdk.java.net/~darcy/8006469.0/

Tests pass as expected; patch below.

Thanks,

-Joe

--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java 
2015-01-09 22:58:28.867563577 -0800
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java 
2015-01-09 22:58:28.771563577 -0800
@@ -26,6 +26,7 @@

  import java.lang.annotation.Annotation;
  import java.lang.annotation.Inherited;
+import java.lang.annotation.Repeatable;
  import java.lang.reflect.InvocationTargetException;
  import java.lang.reflect.Method;

@@ -183,65 +184,12 @@
          return c == null ? null : 
AnnotationProxyMaker.generateAnnotation(c, annoType);
      }

-    // Needed to unpack the runtime view of containing annotations
-    private static final Class<? extends Annotation> REPEATABLE_CLASS = 
initRepeatable();
-    private static final Method VALUE_ELEMENT_METHOD = 
initValueElementMethod();
-
-    private static Class<? extends Annotation> initRepeatable() {
-        try {
-            // Repeatable will not be available when bootstrapping on
-            // JDK 7 so use a reflective lookup instead of a class
-            // literal for Repeatable.class.
-            return 
Class.forName("java.lang.annotation.Repeatable").asSubclass(Annotation.class);
-        } catch (ClassNotFoundException | SecurityException e) {
-            return null;
-        }
-    }
-
-    private static Method initValueElementMethod() {
-        if (REPEATABLE_CLASS == null)
-            return null;
-
-        Method m = null;
-        try {
-            m = REPEATABLE_CLASS.getMethod("value");
-            if (m != null)
-                m.setAccessible(true);
-            return m;
-        } catch (NoSuchMethodException e) {
-            return null;
-        }
-    }
-
-
      // Helper to getAnnotationsByType
      private static Class<? extends Annotation> getContainer(Class<? 
extends Annotation> annoType) {
-        // Since we can not refer to java.lang.annotation.Repeatable 
until we are
-        // bootstrapping with java 8 we need to get the Repeatable 
annotation using
-        // reflective invocations instead of just using its type and 
element method.
-        if (REPEATABLE_CLASS != null &&
-            VALUE_ELEMENT_METHOD != null) {
-            // Get the Repeatable instance on the annotations declaration
-            Annotation repeatable = 
(Annotation)annoType.getAnnotation(REPEATABLE_CLASS);
-            if (repeatable != null) {
-                try {
-                    // Get the value element, it should be a class
-                    // indicating the containing annotation type
-                    @SuppressWarnings("unchecked")
-                    Class<? extends Annotation> containerType = 
(Class)VALUE_ELEMENT_METHOD.invoke(repeatable);
-                    if (containerType == null)
-                        return null;
-
-                    return containerType;
-                } catch (ClassCastException | IllegalAccessException | 
InvocationTargetException e) {
-                    return null;
-                }
-            }
-        }
-        return null;
+        Repeatable repeatable = annoType.getAnnotation(Repeatable.class);
+        return (repeatable == null) ? null : repeatable.value();
      }

-
      // Helper to getAnnotationsByType
      private static Attribute[] unpackAttributes(Attribute.Compound 
container) {
          // We now have an instance of the container,


From pooja.chopra at oracle.com  Mon Jan 12 07:04:25 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Mon, 12 Jan 2015 12:34:25 +0530
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54814528.7020501@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
Message-ID: <54B371F9.8020904@oracle.com>

Hi All,
Please review below fix .

8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails with 
exit code 1
Test bug fix.
https://bugs.openjdk.java.net/browse/JDK-8064454
The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/

Regards,
Pooja
On 12/5/2014 11:09 AM, pooja chopra wrote:
> Hi All,
> Gentle Reminder . Please review below fix .
>
> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
> with exit code 1
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8064454
> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>
> Regards,
> Pooja
> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>
>> Hello,
>> Please review a fix for the issue:
>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>> with exit code 1
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8064454
>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>
>> Thanks
>> Pooja
>


From maurizio.cimadamore at oracle.com  Mon Jan 12 14:32:09 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 12 Jan 2015 14:32:09 +0000
Subject: javac9 and lower bounded wildcards
In-Reply-To: <CAL4Qsgu=SBtJV4UUT8AOwbWXH97-GWM-LJUUUoKWHqojvuVKvg@mail.gmail.com>
References: <CAL4Qsgu=SBtJV4UUT8AOwbWXH97-GWM-LJUUUoKWHqojvuVKvg@mail.gmail.com>
Message-ID: <54B3DAE9.3060607@oracle.com>

I Liam,
this is related to this bug:

https://bugs.openjdk.java.net/browse/JDK-8033718

Fixing that type-system issue caused some most specific issues - this is 
being tracked here:

https://bugs.openjdk.java.net/browse/JDK-8039214

We are aware of the problem and are working on it.

Maurizio


On 09/01/15 18:14, Liam Miller-Cushon wrote:
> This is a bug, right? It reproduces with javac9-dev at head, and might 
> be related to JDK-8067858.
>
> ===
> import java.util.*;
>
> abstract class Test {
>   abstract <T> void f(Collection<? super T> i);
>   abstract <T> void f(List<? super T> i);
>
>   <T> void m(List<T> a) {
>     f(a);
>   }
> }
> ===
>
> Test.java:8: error: reference to f is ambiguous
>     f(a);
>     ^
>   both method <T#1>f(Collection<? super T#1>) in Test and method 
> <T#2>f(List<? super T#2>) in Test match
>   where T#1,T#2 are type-variables:
>     T#1 extends Object declared in method <T#1>f(Collection<? super T#1>)
>     T#2 extends Object declared in method <T#2>f(List<? super T#2>)


From joel.franck at oracle.com  Mon Jan 12 16:22:21 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Mon, 12 Jan 2015 17:22:21 +0100
Subject: JDK 9 RFR of JDK-8006469:Cleanup reflective access of
	java.lang.annotation.Repeatable
In-Reply-To: <54B16AF6.5070804@oracle.com>
References: <54B16AF6.5070804@oracle.com>
Message-ID: <79253029-3704-4F79-967E-4851922343BF@oracle.com>

Time files :)

Looks good!

cheers
/Joel

> On 10 jan 2015, at 19:09, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> With JDK 9 now bootstrapping off of JDK 8, please review this fix to simplify access to the Repeatable annotation within javac; reflective access can be replaced with direct access:
> 
>    http://cr.openjdk.java.net/~darcy/8006469.0/
> 
> Tests pass as expected; patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java 2015-01-09 22:58:28.867563577 -0800
> +++ new/src/jdk.compiler/share/classes/com/sun/tools/javac/code/AnnoConstruct.java 2015-01-09 22:58:28.771563577 -0800
> @@ -26,6 +26,7 @@
> 
> import java.lang.annotation.Annotation;
> import java.lang.annotation.Inherited;
> +import java.lang.annotation.Repeatable;
> import java.lang.reflect.InvocationTargetException;
> import java.lang.reflect.Method;
> 
> @@ -183,65 +184,12 @@
>         return c == null ? null : AnnotationProxyMaker.generateAnnotation(c, annoType);
>     }
> 
> -    // Needed to unpack the runtime view of containing annotations
> -    private static final Class<? extends Annotation> REPEATABLE_CLASS = initRepeatable();
> -    private static final Method VALUE_ELEMENT_METHOD = initValueElementMethod();
> -
> -    private static Class<? extends Annotation> initRepeatable() {
> -        try {
> -            // Repeatable will not be available when bootstrapping on
> -            // JDK 7 so use a reflective lookup instead of a class
> -            // literal for Repeatable.class.
> -            return Class.forName("java.lang.annotation.Repeatable").asSubclass(Annotation.class);
> -        } catch (ClassNotFoundException | SecurityException e) {
> -            return null;
> -        }
> -    }
> -
> -    private static Method initValueElementMethod() {
> -        if (REPEATABLE_CLASS == null)
> -            return null;
> -
> -        Method m = null;
> -        try {
> -            m = REPEATABLE_CLASS.getMethod("value");
> -            if (m != null)
> -                m.setAccessible(true);
> -            return m;
> -        } catch (NoSuchMethodException e) {
> -            return null;
> -        }
> -    }
> -
> -
>     // Helper to getAnnotationsByType
>     private static Class<? extends Annotation> getContainer(Class<? extends Annotation> annoType) {
> -        // Since we can not refer to java.lang.annotation.Repeatable until we are
> -        // bootstrapping with java 8 we need to get the Repeatable annotation using
> -        // reflective invocations instead of just using its type and element method.
> -        if (REPEATABLE_CLASS != null &&
> -            VALUE_ELEMENT_METHOD != null) {
> -            // Get the Repeatable instance on the annotations declaration
> -            Annotation repeatable = (Annotation)annoType.getAnnotation(REPEATABLE_CLASS);
> -            if (repeatable != null) {
> -                try {
> -                    // Get the value element, it should be a class
> -                    // indicating the containing annotation type
> -                    @SuppressWarnings("unchecked")
> -                    Class<? extends Annotation> containerType = (Class)VALUE_ELEMENT_METHOD.invoke(repeatable);
> -                    if (containerType == null)
> -                        return null;
> -
> -                    return containerType;
> -                } catch (ClassCastException | IllegalAccessException | InvocationTargetException e) {
> -                    return null;
> -                }
> -            }
> -        }
> -        return null;
> +        Repeatable repeatable = annoType.getAnnotation(Repeatable.class);
> +        return (repeatable == null) ? null : repeatable.value();
>     }
> 
> -
>     // Helper to getAnnotationsByType
>     private static Attribute[] unpackAttributes(Attribute.Compound container) {
>         // We now have an instance of the container,
> 


From cushon at google.com  Mon Jan 12 18:07:58 2015
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 12 Jan 2015 10:07:58 -0800
Subject: javac9 and lower bounded wildcards
In-Reply-To: <54B3DAE9.3060607@oracle.com>
References: <CAL4Qsgu=SBtJV4UUT8AOwbWXH97-GWM-LJUUUoKWHqojvuVKvg@mail.gmail.com>
	<54B3DAE9.3060607@oracle.com>
Message-ID: <CAL4QsguT7Kgz0qxqKStJ9bHKqAu8=3wOQgTCiiygA_uzZ8jVUw@mail.gmail.com>

Thanks Maurizio. Do you have an estimate for when JDK-8039214 will be
fixed? I'm wondering if it's worth working around to make it easier to test
with 9, or if I should just wait for the patch.

On Mon, Jan 12, 2015 at 6:32 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> I Liam,
> this is related to this bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8033718
>
> Fixing that type-system issue caused some most specific issues - this is
> being tracked here:
>
> https://bugs.openjdk.java.net/browse/JDK-8039214
>
> We are aware of the problem and are working on it.
>
> Maurizio
>
>
>
> On 09/01/15 18:14, Liam Miller-Cushon wrote:
>
>> This is a bug, right? It reproduces with javac9-dev at head, and might be
>> related to JDK-8067858.
>>
>> ===
>> import java.util.*;
>>
>> abstract class Test {
>>   abstract <T> void f(Collection<? super T> i);
>>   abstract <T> void f(List<? super T> i);
>>
>>   <T> void m(List<T> a) {
>>     f(a);
>>   }
>> }
>> ===
>>
>> Test.java:8: error: reference to f is ambiguous
>>     f(a);
>>     ^
>>   both method <T#1>f(Collection<? super T#1>) in Test and method
>> <T#2>f(List<? super T#2>) in Test match
>>   where T#1,T#2 are type-variables:
>>     T#1 extends Object declared in method <T#1>f(Collection<? super T#1>)
>>     T#2 extends Object declared in method <T#2>f(List<? super T#2>)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150112/386da277/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Jan 12 18:46:41 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 12 Jan 2015 18:46:41 +0000
Subject: javac9 and lower bounded wildcards
In-Reply-To: <CAL4QsguT7Kgz0qxqKStJ9bHKqAu8=3wOQgTCiiygA_uzZ8jVUw@mail.gmail.com>
References: <CAL4Qsgu=SBtJV4UUT8AOwbWXH97-GWM-LJUUUoKWHqojvuVKvg@mail.gmail.com>
	<54B3DAE9.3060607@oracle.com>
	<CAL4QsguT7Kgz0qxqKStJ9bHKqAu8=3wOQgTCiiygA_uzZ8jVUw@mail.gmail.com>
Message-ID: <54B41691.1050207@oracle.com>


On 12/01/15 18:07, Liam Miller-Cushon wrote:
> Thanks Maurizio. Do you have an estimate for when JDK-8039214 will be 
> fixed? I'm wondering if it's worth working around to make it easier to 
> test with 9, or if I should just wait for the patch.
Dan is working on it - I'll let him reply to your question; my sense is 
that there's quite a deep trail of type-system fixes involved in order 
to get us there...

Maurizio
>
> On Mon, Jan 12, 2015 at 6:32 AM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     I Liam,
>     this is related to this bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8033718
>
>     Fixing that type-system issue caused some most specific issues -
>     this is being tracked here:
>
>     https://bugs.openjdk.java.net/browse/JDK-8039214
>
>     We are aware of the problem and are working on it.
>
>     Maurizio
>
>
>
>     On 09/01/15 18:14, Liam Miller-Cushon wrote:
>
>         This is a bug, right? It reproduces with javac9-dev at head,
>         and might be related to JDK-8067858.
>
>         ===
>         import java.util.*;
>
>         abstract class Test {
>           abstract <T> void f(Collection<? super T> i);
>           abstract <T> void f(List<? super T> i);
>
>           <T> void m(List<T> a) {
>             f(a);
>           }
>         }
>         ===
>
>         Test.java:8: error: reference to f is ambiguous
>             f(a);
>             ^
>           both method <T#1>f(Collection<? super T#1>) in Test and
>         method <T#2>f(List<? super T#2>) in Test match
>           where T#1,T#2 are type-variables:
>             T#1 extends Object declared in method <T#1>f(Collection<?
>         super T#1>)
>             T#2 extends Object declared in method <T#2>f(List<? super
>         T#2>)
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150112/98b004e8/attachment-0001.html>

From daniel.smith at oracle.com  Tue Jan 13 07:09:48 2015
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 13 Jan 2015 00:09:48 -0700
Subject: javac9 and lower bounded wildcards
In-Reply-To: <CAL4QsguT7Kgz0qxqKStJ9bHKqAu8=3wOQgTCiiygA_uzZ8jVUw@mail.gmail.com>
References: <CAL4Qsgu=SBtJV4UUT8AOwbWXH97-GWM-LJUUUoKWHqojvuVKvg@mail.gmail.com>
	<54B3DAE9.3060607@oracle.com>
	<CAL4QsguT7Kgz0qxqKStJ9bHKqAu8=3wOQgTCiiygA_uzZ8jVUw@mail.gmail.com>
Message-ID: <F5EE4F20-44EB-469D-AF33-AD524C046099@oracle.com>

I'm going to try to have it fixed within a month, but no guarantees.  Could be awhile longer.

?Dan

> On Jan 12, 2015, at 11:07 AM, Liam Miller-Cushon <cushon at google.com> wrote:
> 
> Thanks Maurizio. Do you have an estimate for when JDK-8039214 will be fixed? I'm wondering if it's worth working around to make it easier to test with 9, or if I should just wait for the patch.
> 
> On Mon, Jan 12, 2015 at 6:32 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com>> wrote:
> I Liam,
> this is related to this bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8033718 <https://bugs.openjdk.java.net/browse/JDK-8033718>
> 
> Fixing that type-system issue caused some most specific issues - this is being tracked here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8039214 <https://bugs.openjdk.java.net/browse/JDK-8039214>
> 
> We are aware of the problem and are working on it.
> 
> Maurizio
> 
> 
> 
> On 09/01/15 18:14, Liam Miller-Cushon wrote:
> This is a bug, right? It reproduces with javac9-dev at head, and might be related to JDK-8067858.
> 
> ===
> import java.util.*;
> 
> abstract class Test {
>   abstract <T> void f(Collection<? super T> i);
>   abstract <T> void f(List<? super T> i);
> 
>   <T> void m(List<T> a) {
>     f(a);
>   }
> }
> ===
> 
> Test.java:8: error: reference to f is ambiguous
>     f(a);
>     ^
>   both method <T#1>f(Collection<? super T#1>) in Test and method <T#2>f(List<? super T#2>) in Test match
>   where T#1,T#2 are type-variables:
>     T#1 extends Object declared in method <T#1>f(Collection<? super T#1>)
>     T#2 extends Object declared in method <T#2>f(List<? super T#2>)
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150113/c288015c/attachment.html>

From cushon at google.com  Sat Jan 17 01:16:21 2015
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 16 Jan 2015 17:16:21 -0800
Subject: LVT issue related to JDK-8047719
In-Reply-To: <CAL4QsgtEgFGAhb_XV2cfu6+3f10_2kK0U=UO-uAWV5Q=+BTnBQ@mail.gmail.com>
References: <CAL4Qsgu73rATf-VtVtXuzw6qUgBcK2T0LxCGsKHrSMeYzAMZUg@mail.gmail.com>
	<54752ABF.1000307@oracle.com>
	<CAL4QsgtEgFGAhb_XV2cfu6+3f10_2kK0U=UO-uAWV5Q=+BTnBQ@mail.gmail.com>
Message-ID: <CAL4Qsgt-GbDeZxmsaeB=gohPJSGaRqPsFrBu6ZOw+EKQNh7cEg@mail.gmail.com>

I think this issue is separate, the fix [1] for JDK-8064857 doesn't seem to
help.

Here's the repro again:

class Test {
  {
    String foo = null;
  }
}

Testing with javac9 at head [2], the LVT is still:

      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       7     0  this   LTest;

[1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3bdbc3b8aa14
[2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/230c13955250

On Tue, Nov 25, 2014 at 5:59 PM, Liam Miller-Cushon <cushon at google.com>
wrote:

> Thanks Vicente, I'll try out the patch once it lands.
>
> On Tue, Nov 25, 2014 at 5:19 PM, Vicente-Arturo Romero-Zaldivar <
> vicente.romero at oracle.com> wrote:
>
>> The patch for https://bugs.openjdk.java.net/browse/JDK-8064857, still
>> under review, should fix this issue too.
>>
>> Thanks,
>> Vicente
>>
>>
>> On 11/25/2014 04:54 PM, Liam Miller-Cushon wrote:
>>
>>> An LVT entry is no longer emitted for 'foo' in the following code. The
>>> behaviour changed after the fix for JDK-8047719 [1]. Is this a bug?
>>>
>>> class Test {
>>>   {
>>>     String foo = null;
>>>   }
>>> }
>>>
>>> Before:
>>>       LocalVariableTable:
>>>         Start  Length  Slot  Name   Signature
>>>             6       0     1   foo   Ljava/lang/String;
>>>             0       7     0  this   LTest;
>>>
>>> After:
>>>       LocalVariableTable:
>>>         Start  Length  Slot  Name   Signature
>>>             0       7     0  this   LTest;
>>>
>>> [1] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150116/ddab9508/attachment.html>

From cushon at google.com  Sat Jan 17 01:19:29 2015
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 16 Jan 2015 17:19:29 -0800
Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas
In-Reply-To: <5473812C.5040601@oracle.com>
References: <CAL4QsgvPVOxZAx_2ur-oyObF_e0Dsw23Y+be4NPOYvoMKfc1Sg@mail.gmail.com>
	<546A48FE.5060500@oracle.com> <5473812C.5040601@oracle.com>
Message-ID: <CAL4QsgvkxGUpvQhGnTcU+N8pqy4UzwwY9TzDZ3KTWXB7T239Sw@mail.gmail.com>

Sorry, I lost track of this. Is the patch blocked on anything at my end?

On Mon, Nov 24, 2014 at 11:04 AM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

>  Hi Liam,
>
> I have created this bug entry:
> https://bugs.openjdk.java.net/browse/JDK-8065800 to track this issue.
>
> Thanks,
> Vicente
>
>
> On 11/17/2014 11:14 AM, Vicente-Arturo Romero-Zaldivar wrote:
>
> Hi Liam,
>
> I don't know of any reason to use the position of the arguments as the
> position of the lambda body. I will sponsor your patch,
>
> Thanks,
> Vicente
>
> On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote:
>
> When parsing statement-bodied lambda expressions, javac currently uses the
> start position of the parameter list for the body. This patch fixes the
> parser to record the body's start position correctly.
>
> Example diagnostic before this change:
>
> Test.java:17: error: incompatible types: bad return type in lambda
> expression
>         foo((x) -> { return ""; System.out.println(""); });
>             ^
>
> After:
>
> Test.java:17: error: lambda body is neither value nor void compatible
>         foo((x) -> { return ""; System.out.println(""); });
>                    ^
>
> Placing the caret at the parameter list may be deliberate, but it should
> be possible to do that without recording the body's start position
> incorrectly.
>
> Thanks,
> Liam
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150116/2bde773f/attachment.html>

From forax at univ-mlv.fr  Sat Jan 17 20:22:44 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 17 Jan 2015 21:22:44 +0100
Subject: ClassCastException on collection generics for jdk8 working code
In-Reply-To: <54BAAF23.2020208@gmail.com>
References: <54BA94BD.3000501@gmail.com>	<CAP7YuAQSmVktKbWps2cFe4xhEq-RBr2uyV7OrLT5xdHyPnx1bA@mail.gmail.com>
	<54BAAF23.2020208@gmail.com>
Message-ID: <54BAC494.40505@univ-mlv.fr>

I think this is due to the fix of 8043741 [1].
In my opinion, these legacy tests are buggy and because of a bug in the 
compiler
it was working, and not the other way around.

Anyway, it's just my opinion, there is a lot of corner cases around the 
cast to an interface,
asking the experts is a better idea so I've CC compiler-dev.

R?mi

[1] https://bugs.openjdk.java.net/browse/JDK-8043741

On 01/17/2015 07:51 PM, Emanuel wrote:
> Thank you Martijn, i didn't know :)
>
> here we go :
> https://gist.github.com/tglman/02eb98fb1c80386fa3ab
> https://gist.github.com/tglman/44b0b3fc4239d9229027
>
> Let me add also that OrientDB don't rely in any way on this behavior, it
> come out just from two not well written legacy test case ;).
>
> On 01/17/2015 05:11 PM, Martijn Verburg wrote:
>> Hi Emanuel,
>>
>> Good to see you today! OpenJDK mailing lists strip attachments so
>> you'll need to give a pastebin link or similar.
>>
>> Cheers,
>> Martijn
>>
>> On 17 January 2015 at 16:58, Emanuel <emanuele.tagliaferri at gmail.com
>> <mailto:emanuele.tagliaferri at gmail.com>> wrote:
>>
>>      I am at the Adopt OpenJdk hack day organized by the LJC, I am running
>>      tests cases of OrientDB (open source java based NoSql) on JDK9 (Build
>>      b45 ), and i got some issue with the use of generics.
>>
>>      basically this code:
>>              List<Date> list = new ArrayList<>();
>>              list.add(new Date());
>>
>>              List<Foo> cList = (List<Foo>) (List<?>) list;
>>              Date date = (Date) cList.get(0);                        // it
>>      fail here
>>
>>      on jdk8 it work fine, on jdk9 the code fail in the marked line.
>>
>>      the jdk8 bytecode for the failing line is:
>>            invokeinterface #7,  2            // InterfaceMethod
>>      java/util/List.get:(I)Ljava/lang/Object;
>>            checkcast     #4                  // class java/util/Date
>>
>>      instead of  on jdk9 is:
>>            invokeinterface #7,  2            // InterfaceMethod
>>      java/util/List.get:(I)Ljava/lang/Object;
>>            checkcast     #8                  // class ListFail$Foo
>>            checkcast     #4                  // class java/util/Date
>>
>>
>>      and is clear that there's a additional cast that is causing the
>>      exception.
>>
>>      I understand that this code is not the exactly clean and correct
>>      conceptually, but it may be a lot of this staff out there that can be
>>      break by jdk9.
>>
>>      In attachment a couple of simple example for reproduce this issue.
>>
>>
>>      Regards
>>
>>      Emanuel
>>
>>
>>


From maurizio.cimadamore at oracle.com  Sat Jan 17 21:44:49 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 17 Jan 2015 21:44:49 +0000
Subject: ClassCastException on collection generics for jdk8 working code
In-Reply-To: <54BAC494.40505@univ-mlv.fr>
References: <54BA94BD.3000501@gmail.com>	<CAP7YuAQSmVktKbWps2cFe4xhEq-RBr2uyV7OrLT5xdHyPnx1bA@mail.gmail.com>	<54BAAF23.2020208@gmail.com>
	<54BAC494.40505@univ-mlv.fr>
Message-ID: <54BAD7D1.7060007@oracle.com>

Hi,
I think 8043741 got integrated in b46, so  I would rule that one out 
(also judging from the fix [1], which seems very localized to the 
synthetic nullcheck operators). We'll need to dig a bit deeper on this 
one - the behavior seems a bit weird, and I'm not sure this is intentional.

I'll keep you posted - I agree with Remi that compiler-dev is the right 
mailing list for this one.

Thanks
Maurizio

On 17/01/15 20:22, Remi Forax wrote:
> I think this is due to the fix of 8043741 [1].
> In my opinion, these legacy tests are buggy and because of a bug in 
> the compiler
> it was working, and not the other way around.
>
> Anyway, it's just my opinion, there is a lot of corner cases around 
> the cast to an interface,
> asking the experts is a better idea so I've CC compiler-dev.
>
> R?mi
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8043741
>
> On 01/17/2015 07:51 PM, Emanuel wrote:
>> Thank you Martijn, i didn't know :)
>>
>> here we go :
>> https://gist.github.com/tglman/02eb98fb1c80386fa3ab
>> https://gist.github.com/tglman/44b0b3fc4239d9229027
>>
>> Let me add also that OrientDB don't rely in any way on this behavior, it
>> come out just from two not well written legacy test case ;).
>>
>> On 01/17/2015 05:11 PM, Martijn Verburg wrote:
>>> Hi Emanuel,
>>>
>>> Good to see you today! OpenJDK mailing lists strip attachments so
>>> you'll need to give a pastebin link or similar.
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 17 January 2015 at 16:58, Emanuel <emanuele.tagliaferri at gmail.com
>>> <mailto:emanuele.tagliaferri at gmail.com>> wrote:
>>>
>>>      I am at the Adopt OpenJdk hack day organized by the LJC, I am 
>>> running
>>>      tests cases of OrientDB (open source java based NoSql) on JDK9 
>>> (Build
>>>      b45 ), and i got some issue with the use of generics.
>>>
>>>      basically this code:
>>>              List<Date> list = new ArrayList<>();
>>>              list.add(new Date());
>>>
>>>              List<Foo> cList = (List<Foo>) (List<?>) list;
>>>              Date date = (Date) cList.get(0);                        
>>> // it
>>>      fail here
>>>
>>>      on jdk8 it work fine, on jdk9 the code fail in the marked line.
>>>
>>>      the jdk8 bytecode for the failing line is:
>>>            invokeinterface #7,  2            // InterfaceMethod
>>>      java/util/List.get:(I)Ljava/lang/Object;
>>>            checkcast     #4                  // class java/util/Date
>>>
>>>      instead of  on jdk9 is:
>>>            invokeinterface #7,  2            // InterfaceMethod
>>>      java/util/List.get:(I)Ljava/lang/Object;
>>>            checkcast     #8                  // class ListFail$Foo
>>>            checkcast     #4                  // class java/util/Date
>>>
>>>
>>>      and is clear that there's a additional cast that is causing the
>>>      exception.
>>>
>>>      I understand that this code is not the exactly clean and correct
>>>      conceptually, but it may be a lot of this staff out there that 
>>> can be
>>>      break by jdk9.
>>>
>>>      In attachment a couple of simple example for reproduce this issue.
>>>
>>>
>>>      Regards
>>>
>>>      Emanuel
>>>
>>>
>>>
>


From ali.ebrahimi1781 at gmail.com  Sat Jan 17 22:26:52 2015
From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi)
Date: Sun, 18 Jan 2015 01:56:52 +0330
Subject: ClassCastException on collection generics for jdk8 working code
In-Reply-To: <54BAD7D1.7060007@oracle.com>
References: <54BA94BD.3000501@gmail.com>
	<CAP7YuAQSmVktKbWps2cFe4xhEq-RBr2uyV7OrLT5xdHyPnx1bA@mail.gmail.com>
	<54BAAF23.2020208@gmail.com> <54BAC494.40505@univ-mlv.fr>
	<54BAD7D1.7060007@oracle.com>
Message-ID: <CAA0cW5CuTtmM4DAFh3rM9Yh1NMXU+foSSgBoiZtu6hY9X1PEMQ@mail.gmail.com>

I think root cause is same for both sample code: I think one question
should clear problem and that is how type inference work here:

List<Date> list = new ArrayList<>();
list.add(new Date());

List<Foo> cList = (List<Foo>) (List<?>) list;
Date date = (Date) cList.get(0);

What is result of type inference for "cList.get(0)" ?


Consider that:

Date date = (Date) ((Foo)cList.get(0));

have same result.

I think this is expected behavior.



On Sun, Jan 18, 2015 at 1:14 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi,
> I think 8043741 got integrated in b46, so  I would rule that one out (also
> judging from the fix [1], which seems very localized to the synthetic
> nullcheck operators). We'll need to dig a bit deeper on this one - the
> behavior seems a bit weird, and I'm not sure this is intentional.
>
> I'll keep you posted - I agree with Remi that compiler-dev is the right
> mailing list for this one.
>
> Thanks
> Maurizio
>
>
> On 17/01/15 20:22, Remi Forax wrote:
>
>> I think this is due to the fix of 8043741 [1].
>> In my opinion, these legacy tests are buggy and because of a bug in the
>> compiler
>> it was working, and not the other way around.
>>
>> Anyway, it's just my opinion, there is a lot of corner cases around the
>> cast to an interface,
>> asking the experts is a better idea so I've CC compiler-dev.
>>
>> R?mi
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8043741
>>
>> On 01/17/2015 07:51 PM, Emanuel wrote:
>>
>>> Thank you Martijn, i didn't know :)
>>>
>>> here we go :
>>> https://gist.github.com/tglman/02eb98fb1c80386fa3ab
>>> https://gist.github.com/tglman/44b0b3fc4239d9229027
>>>
>>> Let me add also that OrientDB don't rely in any way on this behavior, it
>>> come out just from two not well written legacy test case ;).
>>>
>>> On 01/17/2015 05:11 PM, Martijn Verburg wrote:
>>>
>>>> Hi Emanuel,
>>>>
>>>> Good to see you today! OpenJDK mailing lists strip attachments so
>>>> you'll need to give a pastebin link or similar.
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>> On 17 January 2015 at 16:58, Emanuel <emanuele.tagliaferri at gmail.com
>>>> <mailto:emanuele.tagliaferri at gmail.com>> wrote:
>>>>
>>>>      I am at the Adopt OpenJdk hack day organized by the LJC, I am
>>>> running
>>>>      tests cases of OrientDB (open source java based NoSql) on JDK9
>>>> (Build
>>>>      b45 ), and i got some issue with the use of generics.
>>>>
>>>>      basically this code:
>>>>              List<Date> list = new ArrayList<>();
>>>>              list.add(new Date());
>>>>
>>>>              List<Foo> cList = (List<Foo>) (List<?>) list;
>>>>              Date date = (Date) cList.get(0);                        //
>>>> it
>>>>      fail here
>>>>
>>>>      on jdk8 it work fine, on jdk9 the code fail in the marked line.
>>>>
>>>>      the jdk8 bytecode for the failing line is:
>>>>            invokeinterface #7,  2            // InterfaceMethod
>>>>      java/util/List.get:(I)Ljava/lang/Object;
>>>>            checkcast     #4                  // class java/util/Date
>>>>
>>>>      instead of  on jdk9 is:
>>>>            invokeinterface #7,  2            // InterfaceMethod
>>>>      java/util/List.get:(I)Ljava/lang/Object;
>>>>            checkcast     #8                  // class ListFail$Foo
>>>>            checkcast     #4                  // class java/util/Date
>>>>
>>>>
>>>>      and is clear that there's a additional cast that is causing the
>>>>      exception.
>>>>
>>>>      I understand that this code is not the exactly clean and correct
>>>>      conceptually, but it may be a lot of this staff out there that can
>>>> be
>>>>      break by jdk9.
>>>>
>>>>      In attachment a couple of simple example for reproduce this issue.
>>>>
>>>>
>>>>      Regards
>>>>
>>>>      Emanuel
>>>>
>>>>
>>>>
>>>>
>>
>


-- 

Best Regards,
Ali Ebrahimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150118/b0c45f9e/attachment.html>

From srikanth.adayapalam at oracle.com  Mon Jan 19 09:39:31 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 19 Jan 2015 15:09:31 +0530
Subject: ClassCastException on collection generics for jdk8 working code
Message-ID: <54BCD0D3.7020304@oracle.com>

Hello !

I have raised https://bugs.openjdk.java.net/browse/JDK-8069265 to track 
this one.
This new behaviour got introduced as of JDK9 build b08 as a result of 
the change
made for https://bugs.openjdk.java.net/browse/JDK-8015499.

Prima facie, there is no indication that there is a compiler bug here. 
The compiler
is well within its rights to assert what it is asserting which fails due 
to CCE. But
we may want to see if we should/could avoid such gratuitous and 
inadvertent behaviour
change.

Thanks!
Srikanth

-------- Forwarded Message --------
Subject: 	Re: ClassCastException on collection generics for jdk8 working 
code
Date: 	Sat, 17 Jan 2015 21:44:49 +0000
From: 	Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
To: 	Remi Forax <forax at univ-mlv.fr>, compiler-dev at openjdk.java.net
CC: 	jdk9-dev at openjdk.java.net



Hi,
I think 8043741 got integrated in b46, so  I would rule that one out
(also judging from the fix [1], which seems very localized to the
synthetic nullcheck operators). We'll need to dig a bit deeper on this
one - the behavior seems a bit weird, and I'm not sure this is intentional.

I'll keep you posted - I agree with Remi that compiler-dev is the right
mailing list for this one.

Thanks
Maurizio

On 17/01/15 20:22, Remi Forax wrote:
> I think this is due to the fix of 8043741 [1].
> In my opinion, these legacy tests are buggy and because of a bug in
> the compiler
> it was working, and not the other way around.
>
> Anyway, it's just my opinion, there is a lot of corner cases around
> the cast to an interface,
> asking the experts is a better idea so I've CC compiler-dev.
>
> R?mi
>
> [1]https://bugs.openjdk.java.net/browse/JDK-8043741
>
> On 01/17/2015 07:51 PM, Emanuel wrote:
>> Thank you Martijn, i didn't know :)
>>
>> here we go :
>>https://gist.github.com/tglman/02eb98fb1c80386fa3ab
>>https://gist.github.com/tglman/44b0b3fc4239d9229027
>>
>> Let me add also that OrientDB don't rely in any way on this behavior, it
>> come out just from two not well written legacy test case ;).
>>
>> On 01/17/2015 05:11 PM, Martijn Verburg wrote:
>>> Hi Emanuel,
>>>
>>> Good to see you today! OpenJDK mailing lists strip attachments so
>>> you'll need to give a pastebin link or similar.
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 17 January 2015 at 16:58, Emanuel<emanuele.tagliaferri at gmail.com
>>><mailto:emanuele.tagliaferri at gmail.com>> wrote:
>>>
>>>      I am at the Adopt OpenJdk hack day organized by the LJC, I am
>>> running
>>>      tests cases of OrientDB (open source java based NoSql) on JDK9
>>> (Build
>>>      b45 ), and i got some issue with the use of generics.
>>>
>>>      basically this code:
>>>              List<Date> list = new ArrayList<>();
>>>              list.add(new Date());
>>>
>>>              List<Foo> cList = (List<Foo>) (List<?>) list;
>>>              Date date = (Date) cList.get(0);
>>> // it
>>>      fail here
>>>
>>>      on jdk8 it work fine, on jdk9 the code fail in the marked line.
>>>
>>>      the jdk8 bytecode for the failing line is:
>>>            invokeinterface #7,  2            // InterfaceMethod
>>>      java/util/List.get:(I)Ljava/lang/Object;
>>>            checkcast     #4                  // class java/util/Date
>>>
>>>      instead of  on jdk9 is:
>>>            invokeinterface #7,  2            // InterfaceMethod
>>>      java/util/List.get:(I)Ljava/lang/Object;
>>>            checkcast     #8                  // class ListFail$Foo
>>>            checkcast     #4                  // class java/util/Date
>>>
>>>
>>>      and is clear that there's a additional cast that is causing the
>>>      exception.
>>>
>>>      I understand that this code is not the exactly clean and correct
>>>      conceptually, but it may be a lot of this staff out there that
>>> can be
>>>      break by jdk9.
>>>
>>>      In attachment a couple of simple example for reproduce this issue.
>>>
>>>
>>>      Regards
>>>
>>>      Emanuel
>>>
>>>
>>>
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150119/c04b5eeb/attachment-0001.html>

From staffan.larsen at oracle.com  Mon Jan 19 10:46:21 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Jan 2015 11:46:21 +0100
Subject: Debuggability of lambdas
Message-ID: <903658F8-2F9A-4E01-B56E-1DDCDE1D09CA@oracle.com>

I would like to get some feedback on my comments in a bug about how we can improve the debuggability of lambdas. Please take a look at: https://bugs.openjdk.java.net/browse/JDK-8054220 <https://bugs.openjdk.java.net/browse/JDK-8054220>

Thanks,
/Staffan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150119/c3092de7/attachment.html>

From maurizio.cimadamore at oracle.com  Mon Jan 19 11:04:16 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 19 Jan 2015 11:04:16 +0000
Subject: Debuggability of lambdas
In-Reply-To: <903658F8-2F9A-4E01-B56E-1DDCDE1D09CA@oracle.com>
References: <903658F8-2F9A-4E01-B56E-1DDCDE1D09CA@oracle.com>
Message-ID: <54BCE4B0.8040509@oracle.com>

Hi Staffan,
I found myself similar problems when trying to debug lambdas, I think 
your proposal seems very reasonable - and pretty much in line with what 
it's done i.e. inside anonymous classes which capture local variables 
from the enclosing scope. By analogy with that example, I'd say that 
variables such as your 'map' should be left alone?

Maurizio

On 19/01/15 10:46, Staffan Larsen wrote:
> I would like to get some feedback on my comments in a bug about how we 
> can improve the debuggability of lambdas. Please take a look at: 
> https://bugs.openjdk.java.net/browse/JDK-8054220
>
> Thanks,
> /Staffan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150119/147436e7/attachment.html>

From staffan.larsen at oracle.com  Mon Jan 19 11:21:08 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 19 Jan 2015 12:21:08 +0100
Subject: Debuggability of lambdas
In-Reply-To: <54BCE4B0.8040509@oracle.com>
References: <903658F8-2F9A-4E01-B56E-1DDCDE1D09CA@oracle.com>
	<54BCE4B0.8040509@oracle.com>
Message-ID: <D344500E-77E9-4E5B-B2EA-2A81384BA85B@oracle.com>

Thank you Maurizio. Yes, the 'map? variable should be left alone. I don?t see how we can (or should) solve that problem.

I should perhaps have mentioned that my interest in this was sparked by a blog post [1] and hacker news item [2].


/Staffan

[1] http://www.rationaljava.com/2015/01/whats-stopping-me-using-java8-lambdas.html
[2] https://news.ycombinator.com/item?id=8906264

> On 19 jan 2015, at 12:04, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi Staffan,
> I found myself similar problems when trying to debug lambdas, I think your proposal seems very reasonable - and pretty much in line with what it's done i.e. inside anonymous classes which capture local variables from the enclosing scope. By analogy with that example, I'd say that variables such as your 'map' should be left alone?
> 
> Maurizio
> 
> On 19/01/15 10:46, Staffan Larsen wrote:
>> I would like to get some feedback on my comments in a bug about how we can improve the debuggability of lambdas. Please take a look at: https://bugs.openjdk.java.net/browse/JDK-8054220 <https://bugs.openjdk.java.net/browse/JDK-8054220>
>> 
>> Thanks,
>> /Staffan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150119/c711e835/attachment.html>

From joel.franck at oracle.com  Mon Jan 19 14:39:22 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Mon, 19 Jan 2015 15:39:22 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD94A3.9050907@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
Message-ID: <AE571131-28B7-433A-9E26-F2F0918AB14B@oracle.com>


> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 1/7/2015 7:22 AM, Timo Walther wrote:
>> the Java Reflection API allows to access the generic signature of
>> methods through the java.lang.reflect.Method#getGenericReturnType()
>> method. However, this is not yet supported for Lambda expressions.
>> 
>> Given the following classes:
>> 
>> class Tuple2<F0,F1> {
>>   F0 field0;
>>   F1 field1;
>> 
>>   public Tuple2(F0 f0, F1 f1) {
>>     this.field0 = f0;
>>     this.field1 = f1;
>>   }
>> }
>> 
>> interface Map<IN, OUT> {
>>   OUT map(IN in);
>> }
>> 
>> Currently, there is no solution that allows to get further type
>> information about expressions like:
>> 
>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>> information about the Tuple2's fields are always lost
> 
> map is a variable, so it doesn't have a return type.
> 
> If map is a class variable or an instance variable, then Field#getGenericType should help.
> 
> Expressions (including lambda expressions) aren't generally exposed through Core Reflection. If an expression (such as a lambda expression) happens to be implemented as a method, then relying on the [generic] signature of that method is dangerous since it may change from release to release.
> 

One could argue that we should generate more attributes for synthetic methods. We did for example add annotations to bridges [1]. While we do want to it discourage depending on a specific translation strategy, I?m not sure adding Signature will make more code break once/if we change translation strategy.

cheers
/Joel

From forax at univ-mlv.fr  Mon Jan 19 15:01:29 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 19 Jan 2015 16:01:29 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <AE571131-28B7-433A-9E26-F2F0918AB14B@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
	<AE571131-28B7-433A-9E26-F2F0918AB14B@oracle.com>
Message-ID: <54BD1C49.2020705@univ-mlv.fr>


On 01/19/2015 03:39 PM, Joel Borggr?n-Franck wrote:
>> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
>>
>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>> the Java Reflection API allows to access the generic signature of
>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>> method. However, this is not yet supported for Lambda expressions.
>>>
>>> Given the following classes:
>>>
>>> class Tuple2<F0,F1> {
>>>    F0 field0;
>>>    F1 field1;
>>>
>>>    public Tuple2(F0 f0, F1 f1) {
>>>      this.field0 = f0;
>>>      this.field1 = f1;
>>>    }
>>> }
>>>
>>> interface Map<IN, OUT> {
>>>    OUT map(IN in);
>>> }
>>>
>>> Currently, there is no solution that allows to get further type
>>> information about expressions like:
>>>
>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>> information about the Tuple2's fields are always lost
>> map is a variable, so it doesn't have a return type.
>>
>> If map is a class variable or an instance variable, then Field#getGenericType should help.
>>
>> Expressions (including lambda expressions) aren't generally exposed through Core Reflection. If an expression (such as a lambda expression) happens to be implemented as a method, then relying on the [generic] signature of that method is dangerous since it may change from release to release.
>>
> One could argue that we should generate more attributes for synthetic methods. We did for example add annotations to bridges [1]. While we do want to it discourage depending on a specific translation strategy, I?m not sure adding Signature will make more code break once/if we change translation strategy.

The problem is not that adding a Signature will break, it's that these 
information will be not available
anymore if we use a strategy based on one lambda proxy shared for 
several lambdas*

>
> cheers
> /Joel

R?mi

*I've a prototype of such strategy but it puts more pressure on lambda 
forms,
I will expose that at the JFokus VM Summit ;)


From joel.franck at oracle.com  Mon Jan 19 15:18:56 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Mon, 19 Jan 2015 16:18:56 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54BD1C49.2020705@univ-mlv.fr>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
	<AE571131-28B7-433A-9E26-F2F0918AB14B@oracle.com>
	<54BD1C49.2020705@univ-mlv.fr>
Message-ID: <0A948861-B6B7-4A66-B3E2-A7EAD404FF19@oracle.com>


> On 19 jan 2015, at 16:01, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> On 01/19/2015 03:39 PM, Joel Borggr?n-Franck wrote:
>>> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
>>> 
>>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>>> the Java Reflection API allows to access the generic signature of
>>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>>> method. However, this is not yet supported for Lambda expressions.
>>>> 
>>>> Given the following classes:
>>>> 
>>>> class Tuple2<F0,F1> {
>>>>   F0 field0;
>>>>   F1 field1;
>>>> 
>>>>   public Tuple2(F0 f0, F1 f1) {
>>>>     this.field0 = f0;
>>>>     this.field1 = f1;
>>>>   }
>>>> }
>>>> 
>>>> interface Map<IN, OUT> {
>>>>   OUT map(IN in);
>>>> }
>>>> 
>>>> Currently, there is no solution that allows to get further type
>>>> information about expressions like:
>>>> 
>>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>>> information about the Tuple2's fields are always lost
>>> map is a variable, so it doesn't have a return type.
>>> 
>>> If map is a class variable or an instance variable, then Field#getGenericType should help.
>>> 
>>> Expressions (including lambda expressions) aren't generally exposed through Core Reflection. If an expression (such as a lambda expression) happens to be implemented as a method, then relying on the [generic] signature of that method is dangerous since it may change from release to release.
>>> 
>> One could argue that we should generate more attributes for synthetic methods. We did for example add annotations to bridges [1]. While we do want to it discourage depending on a specific translation strategy, I?m not sure adding Signature will make more code break once/if we change translation strategy.
> 
> The problem is not that adding a Signature will break, it's that these information will be not available
> anymore if we use a strategy based on one lambda proxy shared for several lambdas*

But isn?t this unrelated? I?m saying it might be reasonable to expect _a_ Signature for a generic method even if it is synthetic. To me it sounds like that signature will be much less specific in your prototype, but it can still exist?

cheers
/Joel


From forax at univ-mlv.fr  Mon Jan 19 15:29:19 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 19 Jan 2015 16:29:19 +0100
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <0A948861-B6B7-4A66-B3E2-A7EAD404FF19@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
	<AE571131-28B7-433A-9E26-F2F0918AB14B@oracle.com>
	<54BD1C49.2020705@univ-mlv.fr>
	<0A948861-B6B7-4A66-B3E2-A7EAD404FF19@oracle.com>
Message-ID: <54BD22CF.8070502@univ-mlv.fr>


On 01/19/2015 04:18 PM, Joel Borggr?n-Franck wrote:
>> On 19 jan 2015, at 16:01, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> On 01/19/2015 03:39 PM, Joel Borggr?n-Franck wrote:
>>>> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
>>>>
>>>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>>>> the Java Reflection API allows to access the generic signature of
>>>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>>>> method. However, this is not yet supported for Lambda expressions.
>>>>>
>>>>> Given the following classes:
>>>>>
>>>>> class Tuple2<F0,F1> {
>>>>>    F0 field0;
>>>>>    F1 field1;
>>>>>
>>>>>    public Tuple2(F0 f0, F1 f1) {
>>>>>      this.field0 = f0;
>>>>>      this.field1 = f1;
>>>>>    }
>>>>> }
>>>>>
>>>>> interface Map<IN, OUT> {
>>>>>    OUT map(IN in);
>>>>> }
>>>>>
>>>>> Currently, there is no solution that allows to get further type
>>>>> information about expressions like:
>>>>>
>>>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>>>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>>>> information about the Tuple2's fields are always lost
>>>> map is a variable, so it doesn't have a return type.
>>>>
>>>> If map is a class variable or an instance variable, then Field#getGenericType should help.
>>>>
>>>> Expressions (including lambda expressions) aren't generally exposed through Core Reflection. If an expression (such as a lambda expression) happens to be implemented as a method, then relying on the [generic] signature of that method is dangerous since it may change from release to release.
>>>>
>>> One could argue that we should generate more attributes for synthetic methods. We did for example add annotations to bridges [1]. While we do want to it discourage depending on a specific translation strategy, I?m not sure adding Signature will make more code break once/if we change translation strategy.
>> The problem is not that adding a Signature will break, it's that these information will be not available
>> anymore if we use a strategy based on one lambda proxy shared for several lambdas*
> But isn?t this unrelated? I?m saying it might be reasonable to expect _a_ Signature for a generic method even if it is synthetic. To me it sounds like that signature will be much less specific in your prototype, but it can still exist?

err, sorry not clear,
Yes, you're right, the signature will still exist but there will be no 
way at runtime to get a reference (in the generic sense) to the 
synthetic method. Because the link from a lambda proxy to the lambda 
implementation will be hidden.

>
> cheers
> /Joel
>

cheers,
R?mi


From john.r.rose at oracle.com  Mon Jan 19 22:33:37 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 19 Jan 2015 14:33:37 -0800
Subject: Debuggability of lambdas
In-Reply-To: <54BCE4B0.8040509@oracle.com>
References: <903658F8-2F9A-4E01-B56E-1DDCDE1D09CA@oracle.com>
	<54BCE4B0.8040509@oracle.com>
Message-ID: <8CA31BAC-A82A-411D-BAFB-0675BF53D1C5@oracle.com>

On Jan 19, 2015, at 3:04 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
>  I think your proposal seems very reasonable - and pretty much in line with what it's done i.e. inside anonymous classes which capture local variables from the enclosing scope. By analogy with that example, I'd say that variables such as your 'map' should be left alone?

+1  The inner classes support for debuggers is pretty simple; we assign the synthetic copy the same name as the original value.

The synthetic copies should be marked final, so nobody tries to "set" them from a debugger.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150119/7420cb7b/attachment.html>

From joel.franck at oracle.com  Wed Jan 21 17:27:43 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Wed, 21 Jan 2015 18:27:43 +0100
Subject: RFR 8070507: LambdaLambdaSerialized can fail in -agentvm mode
Message-ID: <A9E80C97-15E3-4425-8FA4-6A1229848DB6@oracle.com>

Hi,

Can I get a review for this small fix for two tests that can interfere with each other when run concurrently.

Fix is to move the interfaces to be nested instead of auxiliary. Patch inline.

cheers
/Joel

diff -r 1580b10e028a test/tools/javac/lambda/LambdaLambdaSerialized.java
--- a/test/tools/javac/lambda/LambdaLambdaSerialized.java       Tue Jan 20 21:49:55 2015 +0100
+++ b/test/tools/javac/lambda/LambdaLambdaSerialized.java       Wed Jan 21 18:09:47 2015 +0100
@@ -67,13 +67,13 @@
         out.writeObject(lamb);
     }

-    static void readAssert(ObjectInputStream in, String expected)  throws IOException, ClassNotFoundException {
-        LSI<LSI<Map>> ls = (LSI<LSI<Map>>) in.readObject();
+    static void readAssert(ObjectInputStream in, String expected) throws IOException, ClassNotFoundException {
+        LSI<LSI<Map>> ls = (LSI<LSI<Map>>)in.readObject();
         Map result = ls.get().get();
         System.out.printf("Result: %s\n", result);
     }
+
+    interface LSI<T> extends Serializable {
+        T get();
+    }
 }
-
-interface LSI<T> extends Serializable {
-    T get();
-}
diff -r 1580b10e028a test/tools/javac/lambda/SerializedLambdaInInit.java
--- a/test/tools/javac/lambda/SerializedLambdaInInit.java       Tue Jan 20 21:49:55 2015 +0100
+++ b/test/tools/javac/lambda/SerializedLambdaInInit.java       Wed Jan 21 18:09:47 2015 +0100
@@ -111,8 +111,8 @@
             }
         }
     }
+
+    interface LSI extends Serializable {
+        String convert(String x);
+    }
 }
-
-interface LSI extends Serializable {
-    String convert(String x);
-}

From maurizio.cimadamore at oracle.com  Wed Jan 21 17:30:56 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 21 Jan 2015 17:30:56 +0000
Subject: RFR 8070507: LambdaLambdaSerialized can fail in -agentvm mode
In-Reply-To: <A9E80C97-15E3-4425-8FA4-6A1229848DB6@oracle.com>
References: <A9E80C97-15E3-4425-8FA4-6A1229848DB6@oracle.com>
Message-ID: <54BFE250.2010405@oracle.com>

Looks good!

Maurizio
On 21/01/15 17:27, Joel Borggr?n-Franck wrote:
> Hi,
>
> Can I get a review for this small fix for two tests that can interfere with each other when run concurrently.
>
> Fix is to move the interfaces to be nested instead of auxiliary. Patch inline.
>
> cheers
> /Joel
>
> diff -r 1580b10e028a test/tools/javac/lambda/LambdaLambdaSerialized.java
> --- a/test/tools/javac/lambda/LambdaLambdaSerialized.java       Tue Jan 20 21:49:55 2015 +0100
> +++ b/test/tools/javac/lambda/LambdaLambdaSerialized.java       Wed Jan 21 18:09:47 2015 +0100
> @@ -67,13 +67,13 @@
>           out.writeObject(lamb);
>       }
>
> -    static void readAssert(ObjectInputStream in, String expected)  throws IOException, ClassNotFoundException {
> -        LSI<LSI<Map>> ls = (LSI<LSI<Map>>) in.readObject();
> +    static void readAssert(ObjectInputStream in, String expected) throws IOException, ClassNotFoundException {
> +        LSI<LSI<Map>> ls = (LSI<LSI<Map>>)in.readObject();
>           Map result = ls.get().get();
>           System.out.printf("Result: %s\n", result);
>       }
> +
> +    interface LSI<T> extends Serializable {
> +        T get();
> +    }
>   }
> -
> -interface LSI<T> extends Serializable {
> -    T get();
> -}
> diff -r 1580b10e028a test/tools/javac/lambda/SerializedLambdaInInit.java
> --- a/test/tools/javac/lambda/SerializedLambdaInInit.java       Tue Jan 20 21:49:55 2015 +0100
> +++ b/test/tools/javac/lambda/SerializedLambdaInInit.java       Wed Jan 21 18:09:47 2015 +0100
> @@ -111,8 +111,8 @@
>               }
>           }
>       }
> +
> +    interface LSI extends Serializable {
> +        String convert(String x);
> +    }
>   }
> -
> -interface LSI extends Serializable {
> -    String convert(String x);
> -}


From sean.coffey at oracle.com  Thu Jan 22 13:06:42 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 22 Jan 2015 13:06:42 +0000
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54B371F9.8020904@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com>
Message-ID: <54C0F5E2.2030609@oracle.com>

Pooja,

your test case fix looks fine to me but I'm not a jdk7u reviewer. Can we 
get a jdk7u reviewer to review this simple change please ?

regards,
Sean.

On 12/01/2015 07:04, pooja chopra wrote:
> Hi All,
> Please review below fix .
>
> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
> with exit code 1
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8064454
> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>
> Regards,
> Pooja
> On 12/5/2014 11:09 AM, pooja chopra wrote:
>> Hi All,
>> Gentle Reminder . Please review below fix .
>>
>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>> with exit code 1
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8064454
>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>
>> Regards,
>> Pooja
>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>
>>> Hello,
>>> Please review a fix for the issue:
>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>> with exit code 1
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>
>>> Thanks
>>> Pooja
>>
>


From maurizio.cimadamore at oracle.com  Thu Jan 22 13:35:17 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 22 Jan 2015 13:35:17 +0000
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54B371F9.8020904@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com>
Message-ID: <54C0FC95.90807@oracle.com>

It seems like the problematic rm in the last line has been removed i.e. 
in JDK 8?

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/2d2b2be57c78/test/tools/javac/innerClassFile/Driver.sh

Perhaps, instead of tweaking permission, we should just do things the 
JDK 8 way?

Maurizio

On 12/01/15 07:04, pooja chopra wrote:
> Hi All,
> Please review below fix .
>
> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
> with exit code 1
> Test bug fix.
> https://bugs.openjdk.java.net/browse/JDK-8064454
> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>
> Regards,
> Pooja
> On 12/5/2014 11:09 AM, pooja chopra wrote:
>> Hi All,
>> Gentle Reminder . Please review below fix .
>>
>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>> with exit code 1
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8064454
>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>
>> Regards,
>> Pooja
>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>
>>> Hello,
>>> Please review a fix for the issue:
>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>> with exit code 1
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>
>>> Thanks
>>> Pooja
>>
>


From pooja.chopra at oracle.com  Thu Jan 22 17:43:15 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Thu, 22 Jan 2015 23:13:15 +0530
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54C0FC95.90807@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com> <54C0FC95.90807@oracle.com>
Message-ID: <54C136B3.1070704@oracle.com>

Hi Maurizio,

In JDK 8  as I saw ' rm -rf src  '  line of code has been simply removed 
from the code  but  "src"  folder was temporarily created using 'mkdir 
src' in the Driver.sh code so I believe it should be removed if its 
created after use. Please suggest further .

Regards,
Pooja
On 1/22/2015 7:05 PM, Maurizio Cimadamore wrote:
> It seems like the problematic rm in the last line has been removed 
> i.e. in JDK 8?
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/2d2b2be57c78/test/tools/javac/innerClassFile/Driver.sh 
>
>
> Perhaps, instead of tweaking permission, we should just do things the 
> JDK 8 way?
>
> Maurizio
>
> On 12/01/15 07:04, pooja chopra wrote:
>> Hi All,
>> Please review below fix .
>>
>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>> with exit code 1
>> Test bug fix.
>> https://bugs.openjdk.java.net/browse/JDK-8064454
>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>
>> Regards,
>> Pooja
>> On 12/5/2014 11:09 AM, pooja chopra wrote:
>>> Hi All,
>>> Gentle Reminder . Please review below fix .
>>>
>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>> with exit code 1
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>
>>> Regards,
>>> Pooja
>>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>>
>>>> Hello,
>>>> Please review a fix for the issue:
>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>>> with exit code 1
>>>> Test bug fix.
>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>
>>>> Thanks
>>>> Pooja
>>>
>>
>


From pooja.chopra at oracle.com  Thu Jan 22 17:47:23 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Thu, 22 Jan 2015 23:17:23 +0530
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54C136B3.1070704@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com> <54C0FC95.90807@oracle.com>
	<54C136B3.1070704@oracle.com>
Message-ID: <54C137AB.6090404@oracle.com>

Hi Maurizio ,

There is already a bug JDK-8057527 
<https://bugs.openjdk.java.net/browse/JDK-8057527>: 
tools/javac/innerClassFile/Driver.sh fails to cleanup files after it 
because of which ' rm -rf src  ' piece of code was added so if we remove 
this then again bug JDK-8057527 
<https://bugs.openjdk.java.net/browse/JDK-8057527> will occur.

Regards,
Pooja
On 1/22/2015 11:13 PM, pooja chopra wrote:
> Hi Maurizio,
>
> In JDK 8  as I saw ' rm -rf src  '  line of code has been simply 
> removed from the code  but  "src"  folder was temporarily created 
> using 'mkdir src' in the Driver.sh code so I believe it should be 
> removed if its created after use. Please suggest further .
>
> Regards,
> Pooja
> On 1/22/2015 7:05 PM, Maurizio Cimadamore wrote:
>> It seems like the problematic rm in the last line has been removed 
>> i.e. in JDK 8?
>>
>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/2d2b2be57c78/test/tools/javac/innerClassFile/Driver.sh 
>>
>>
>> Perhaps, instead of tweaking permission, we should just do things the 
>> JDK 8 way?
>>
>> Maurizio
>>
>> On 12/01/15 07:04, pooja chopra wrote:
>>> Hi All,
>>> Please review below fix .
>>>
>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>> with exit code 1
>>> Test bug fix.
>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>
>>> Regards,
>>> Pooja
>>> On 12/5/2014 11:09 AM, pooja chopra wrote:
>>>> Hi All,
>>>> Gentle Reminder . Please review below fix .
>>>>
>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>>> with exit code 1
>>>> Test bug fix.
>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>
>>>> Regards,
>>>> Pooja
>>>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>>>
>>>>> Hello,
>>>>> Please review a fix for the issue:
>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>>>> with exit code 1
>>>>> Test bug fix.
>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>
>>>>> Thanks
>>>>> Pooja
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/cb6f1607/attachment.html>

From vicente.romero at oracle.com  Thu Jan 22 18:10:23 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 22 Jan 2015 10:10:23 -0800
Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas
In-Reply-To: <CAL4QsgvkxGUpvQhGnTcU+N8pqy4UzwwY9TzDZ3KTWXB7T239Sw@mail.gmail.com>
References: <CAL4QsgvPVOxZAx_2ur-oyObF_e0Dsw23Y+be4NPOYvoMKfc1Sg@mail.gmail.com>
	<546A48FE.5060500@oracle.com> <5473812C.5040601@oracle.com>
	<CAL4QsgvkxGUpvQhGnTcU+N8pqy4UzwwY9TzDZ3KTWXB7T239Sw@mail.gmail.com>
Message-ID: <54C13D0F.2080508@oracle.com>

Hi Liam,

The bug is a P4, so it's only blocked for other bugs / projects with 
higher priority I'm working on. I will take a look at it later this week,

Thanks,
Vicente

On 01/16/2015 05:19 PM, Liam Miller-Cushon wrote:
> Sorry, I lost track of this. Is the patch blocked on anything at my end?
>
> On Mon, Nov 24, 2014 at 11:04 AM, Vicente-Arturo Romero-Zaldivar 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     Hi Liam,
>
>     I have created this bug entry:
>     https://bugs.openjdk.java.net/browse/JDK-8065800 to track this issue.
>
>     Thanks,
>     Vicente
>
>
>     On 11/17/2014 11:14 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>     Hi Liam,
>>
>>     I don't know of any reason to use the position of the arguments
>>     as the position of the lambda body. I will sponsor your patch,
>>
>>     Thanks,
>>     Vicente
>>
>>     On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote:
>>>     When parsing statement-bodied lambda expressions, javac
>>>     currently uses the start position of the parameter list for the
>>>     body. This patch fixes the parser to record the body's start
>>>     position correctly.
>>>
>>>     Example diagnostic before this change:
>>>
>>>     Test.java:17: error: incompatible types: bad return type in
>>>     lambda expression
>>>     foo((x) -> { return ""; System.out.println(""); });
>>>     ^
>>>
>>>     After:
>>>
>>>     Test.java:17: error: lambda body is neither value nor void
>>>     compatible
>>>     foo((x) -> { return ""; System.out.println(""); });
>>>              ^
>>>
>>>     Placing the caret at the parameter list may be deliberate, but
>>>     it should be possible to do that without recording the body's
>>>     start position incorrectly.
>>>
>>>     Thanks,
>>>     Liam
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/d130103d/attachment.html>

From vicente.romero at oracle.com  Thu Jan 22 18:21:42 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 22 Jan 2015 10:21:42 -0800
Subject: LVT issue related to JDK-8047719
In-Reply-To: <CAL4Qsgt-GbDeZxmsaeB=gohPJSGaRqPsFrBu6ZOw+EKQNh7cEg@mail.gmail.com>
References: <CAL4Qsgu73rATf-VtVtXuzw6qUgBcK2T0LxCGsKHrSMeYzAMZUg@mail.gmail.com>
	<54752ABF.1000307@oracle.com>
	<CAL4QsgtEgFGAhb_XV2cfu6+3f10_2kK0U=UO-uAWV5Q=+BTnBQ@mail.gmail.com>
	<CAL4Qsgt-GbDeZxmsaeB=gohPJSGaRqPsFrBu6ZOw+EKQNh7cEg@mail.gmail.com>
Message-ID: <54C13FB6.9050103@oracle.com>

Hi Liam,

Question: why is this difference important for you? or in other words, 
why is it important to have an LVT entry for a variable with length 0? 
The spec doesn't say that it should be represented in the LVT and 
actually a reading of the spec could imply that they shouldn't be 
represented. The spec says that, I'm not quoting it:

LVT represents ranges from [start, end) where the right extreme is not 
included in the range.

 From this lecture a variable with length 0, is not that it shouldn't be 
represented but is that it can't be represented as the range [start, 
start) is empty.

Thanks,
Vicente

On 01/16/2015 05:16 PM, Liam Miller-Cushon wrote:
> I think this issue is separate, the fix [1] for JDK-8064857 doesn't 
> seem to help.
>
> Here's the repro again:
>
> class Test {
>   {
>     String foo = null;
>   }
> }
>
> Testing with javac9 at head [2], the LVT is still:
>
>       LocalVariableTable:
>         Start  Length  Slot  Name   Signature
>             0       7     0  this   LTest;
>
> [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3bdbc3b8aa14
> [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/230c13955250
>
> On Tue, Nov 25, 2014 at 5:59 PM, Liam Miller-Cushon <cushon at google.com 
> <mailto:cushon at google.com>> wrote:
>
>     Thanks Vicente, I'll try out the patch once it lands.
>
>     On Tue, Nov 25, 2014 at 5:19 PM, Vicente-Arturo Romero-Zaldivar
>     <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>         The patch for
>         https://bugs.openjdk.java.net/browse/JDK-8064857, still under
>         review, should fix this issue too.
>
>         Thanks,
>         Vicente
>
>
>         On 11/25/2014 04:54 PM, Liam Miller-Cushon wrote:
>
>             An LVT entry is no longer emitted for 'foo' in the
>             following code. The behaviour changed after the fix for
>             JDK-8047719 [1]. Is this a bug?
>
>             class Test {
>               {
>                 String foo = null;
>               }
>             }
>
>             Before:
>                   LocalVariableTable:
>                     Start  Length  Slot  Name  Signature
>                         6       0     1   foo  Ljava/lang/String;
>                         0       7     0  this  LTest;
>
>             After:
>                   LocalVariableTable:
>                     Start  Length  Slot  Name  Signature
>                         0       7     0  this  LTest;
>
>             [1]
>             http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/61b9942d/attachment-0001.html>

From cushon at google.com  Thu Jan 22 22:45:04 2015
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 22 Jan 2015 14:45:04 -0800
Subject: LVT issue related to JDK-8047719
In-Reply-To: <54C13FB6.9050103@oracle.com>
References: <CAL4Qsgu73rATf-VtVtXuzw6qUgBcK2T0LxCGsKHrSMeYzAMZUg@mail.gmail.com>
	<54752ABF.1000307@oracle.com>
	<CAL4QsgtEgFGAhb_XV2cfu6+3f10_2kK0U=UO-uAWV5Q=+BTnBQ@mail.gmail.com>
	<CAL4Qsgt-GbDeZxmsaeB=gohPJSGaRqPsFrBu6ZOw+EKQNh7cEg@mail.gmail.com>
	<54C13FB6.9050103@oracle.com>
Message-ID: <CAL4Qsgt=T2=62D9_QOejCK3i56Dj9j4Ayn1uT7_SaXC-k1CUtA@mail.gmail.com>

I discovered this because some code was doing bytecode introspection to
find all of the types referenced in a method declaration, and this change
causes types that were previously only referenced in the LVT to be
invisible.

I agree that the spec doesn't allow this variable to be represented in the
LVT, and it doesn't seem like the information would be useful to debuggers
anyways. I'll update the code that was relying on the old behaviour.

Thanks for the explanation,
Liam

On Thu, Jan 22, 2015 at 10:21 AM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

>  Hi Liam,
>
> Question: why is this difference important for you? or in other words, why
> is it important to have an LVT entry for a variable with length 0? The spec
> doesn't say that it should be represented in the LVT and actually a reading
> of the spec could imply that they shouldn't be represented. The spec says
> that, I'm not quoting it:
>
> LVT represents ranges from [start, end) where the right extreme is not
> included in the range.
>
> From this lecture a variable with length 0, is not that it shouldn't be
> represented but is that it can't be represented as the range [start, start)
> is empty.
>
> Thanks,
> Vicente
>
>
> On 01/16/2015 05:16 PM, Liam Miller-Cushon wrote:
>
> I think this issue is separate, the fix [1] for JDK-8064857 doesn't seem
> to help.
>
>  Here's the repro again:
>
>  class Test {
>   {
>     String foo = null;
>   }
> }
>
>  Testing with javac9 at head [2], the LVT is still:
>
>        LocalVariableTable:
>         Start  Length  Slot  Name   Signature
>             0       7     0  this   LTest;
>
>  [1] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3bdbc3b8aa14
> [2] http://hg.openjdk.java.net/jdk9/dev/langtools/rev/230c13955250
>
> On Tue, Nov 25, 2014 at 5:59 PM, Liam Miller-Cushon <cushon at google.com>
> wrote:
>
>> Thanks Vicente, I'll try out the patch once it lands.
>>
>> On Tue, Nov 25, 2014 at 5:19 PM, Vicente-Arturo Romero-Zaldivar <
>> vicente.romero at oracle.com> wrote:
>>
>>> The patch for https://bugs.openjdk.java.net/browse/JDK-8064857, still
>>> under review, should fix this issue too.
>>>
>>> Thanks,
>>> Vicente
>>>
>>>
>>> On 11/25/2014 04:54 PM, Liam Miller-Cushon wrote:
>>>
>>>> An LVT entry is no longer emitted for 'foo' in the following code. The
>>>> behaviour changed after the fix for JDK-8047719 [1]. Is this a bug?
>>>>
>>>> class Test {
>>>>   {
>>>>     String foo = null;
>>>>   }
>>>> }
>>>>
>>>> Before:
>>>>       LocalVariableTable:
>>>>         Start  Length  Slot  Name   Signature
>>>>             6       0     1   foo   Ljava/lang/String;
>>>>             0       7     0  this   LTest;
>>>>
>>>> After:
>>>>       LocalVariableTable:
>>>>         Start  Length  Slot  Name   Signature
>>>>             0       7     0  this   LTest;
>>>>
>>>> [1] http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/855f8c7337eb
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/b6dd67a5/attachment.html>

From cushon at google.com  Thu Jan 22 22:48:23 2015
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 22 Jan 2015 14:48:23 -0800
Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas
In-Reply-To: <54C13D0F.2080508@oracle.com>
References: <CAL4QsgvPVOxZAx_2ur-oyObF_e0Dsw23Y+be4NPOYvoMKfc1Sg@mail.gmail.com>
	<546A48FE.5060500@oracle.com> <5473812C.5040601@oracle.com>
	<CAL4QsgvkxGUpvQhGnTcU+N8pqy4UzwwY9TzDZ3KTWXB7T239Sw@mail.gmail.com>
	<54C13D0F.2080508@oracle.com>
Message-ID: <CAL4Qsgvn8_sCusGW1G1dzwkFpxxKxw1=XW39KQrzGM2Z1Hfu=A@mail.gmail.com>

Thanks Vicente. There's no rush, I just wanted to make sure it didn't get
lost.

On Thu, Jan 22, 2015 at 10:10 AM, Vicente-Arturo Romero-Zaldivar <
vicente.romero at oracle.com> wrote:

>  Hi Liam,
>
> The bug is a P4, so it's only blocked for other bugs / projects with
> higher priority I'm working on. I will take a look at it later this week,
>
> Thanks,
> Vicente
>
>
> On 01/16/2015 05:19 PM, Liam Miller-Cushon wrote:
>
> Sorry, I lost track of this. Is the patch blocked on anything at my end?
>
> On Mon, Nov 24, 2014 at 11:04 AM, Vicente-Arturo Romero-Zaldivar <
> vicente.romero at oracle.com> wrote:
>
>>  Hi Liam,
>>
>> I have created this bug entry:
>> https://bugs.openjdk.java.net/browse/JDK-8065800 to track this issue.
>>
>> Thanks,
>> Vicente
>>
>>
>> On 11/17/2014 11:14 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>
>> Hi Liam,
>>
>> I don't know of any reason to use the position of the arguments as the
>> position of the lambda body. I will sponsor your patch,
>>
>> Thanks,
>> Vicente
>>
>> On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote:
>>
>> When parsing statement-bodied lambda expressions, javac currently uses
>> the start position of the parameter list for the body. This patch fixes the
>> parser to record the body's start position correctly.
>>
>> Example diagnostic before this change:
>>
>> Test.java:17: error: incompatible types: bad return type in lambda
>> expression
>>         foo((x) -> { return ""; System.out.println(""); });
>>             ^
>>
>> After:
>>
>> Test.java:17: error: lambda body is neither value nor void compatible
>>         foo((x) -> { return ""; System.out.println(""); });
>>                    ^
>>
>> Placing the caret at the parameter list may be deliberate, but it should
>> be possible to do that without recording the body's start position
>> incorrectly.
>>
>> Thanks,
>> Liam
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/bbe0fd8f/attachment.html>

From vicente.romero at oracle.com  Thu Jan 22 23:14:45 2015
From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar)
Date: Thu, 22 Jan 2015 15:14:45 -0800
Subject: [PATCH] Diagnostic position fix for statement-bodied lambdas
In-Reply-To: <CAL4Qsgvn8_sCusGW1G1dzwkFpxxKxw1=XW39KQrzGM2Z1Hfu=A@mail.gmail.com>
References: <CAL4QsgvPVOxZAx_2ur-oyObF_e0Dsw23Y+be4NPOYvoMKfc1Sg@mail.gmail.com>
	<546A48FE.5060500@oracle.com> <5473812C.5040601@oracle.com>
	<CAL4QsgvkxGUpvQhGnTcU+N8pqy4UzwwY9TzDZ3KTWXB7T239Sw@mail.gmail.com>
	<54C13D0F.2080508@oracle.com>
	<CAL4Qsgvn8_sCusGW1G1dzwkFpxxKxw1=XW39KQrzGM2Z1Hfu=A@mail.gmail.com>
Message-ID: <54C18465.9070500@oracle.com>

On 01/22/2015 02:48 PM, Liam Miller-Cushon wrote:
> Thanks Vicente. There's no rush, I just wanted to make sure it didn't 
> get lost.

Sure np,

Thanks,
Vicente

>
> On Thu, Jan 22, 2015 at 10:10 AM, Vicente-Arturo Romero-Zaldivar 
> <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>
>     Hi Liam,
>
>     The bug is a P4, so it's only blocked for other bugs / projects
>     with higher priority I'm working on. I will take a look at it
>     later this week,
>
>     Thanks,
>     Vicente
>
>
>     On 01/16/2015 05:19 PM, Liam Miller-Cushon wrote:
>>     Sorry, I lost track of this. Is the patch blocked on anything at
>>     my end?
>>
>>     On Mon, Nov 24, 2014 at 11:04 AM, Vicente-Arturo Romero-Zaldivar
>>     <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>> wrote:
>>
>>         Hi Liam,
>>
>>         I have created this bug entry:
>>         https://bugs.openjdk.java.net/browse/JDK-8065800 to track
>>         this issue.
>>
>>         Thanks,
>>         Vicente
>>
>>
>>         On 11/17/2014 11:14 AM, Vicente-Arturo Romero-Zaldivar wrote:
>>>         Hi Liam,
>>>
>>>         I don't know of any reason to use the position of the
>>>         arguments as the position of the lambda body. I will sponsor
>>>         your patch,
>>>
>>>         Thanks,
>>>         Vicente
>>>
>>>         On 11/14/2014 05:16 PM, Liam Miller-Cushon wrote:
>>>>         When parsing statement-bodied lambda expressions, javac
>>>>         currently uses the start position of the parameter list for
>>>>         the body. This patch fixes the parser to record the body's
>>>>         start position correctly.
>>>>
>>>>         Example diagnostic before this change:
>>>>
>>>>         Test.java:17: error: incompatible types: bad return type in
>>>>         lambda expression
>>>>               foo((x) -> { return ""; System.out.println(""); });
>>>>                   ^
>>>>
>>>>         After:
>>>>
>>>>         Test.java:17: error: lambda body is neither value nor void
>>>>         compatible
>>>>               foo((x) -> { return ""; System.out.println(""); });
>>>>                          ^
>>>>
>>>>         Placing the caret at the parameter list may be deliberate,
>>>>         but it should be possible to do that without recording the
>>>>         body's start position incorrectly.
>>>>
>>>>         Thanks,
>>>>         Liam
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150122/65a74075/attachment-0001.html>

From sewen at apache.org  Sat Jan 24 19:01:48 2015
From: sewen at apache.org (Stephan Ewen)
Date: Sat, 24 Jan 2015 11:01:48 -0800
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54BD22CF.8070502@univ-mlv.fr>
References: <54AD4F24.2080605@apache.org> <54AD94A3.9050907@oracle.com>
	<AE571131-28B7-433A-9E26-F2F0918AB14B@oracle.com>
	<54BD1C49.2020705@univ-mlv.fr>
	<0A948861-B6B7-4A66-B3E2-A7EAD404FF19@oracle.com>
	<54BD22CF.8070502@univ-mlv.fr>
Message-ID: <CANC1h_v7QQvtvLk76e-vfeQntSL_=R=js61TgaNuk+uw5Thn0A@mail.gmail.com>

If I understand things correctly (please help me if I am wrong, I am not a
deep expert in this field) the main concern is:

Is it a good idea (or later possible at all) to grab a reference at all to
the synthetic method generated for the lambda, since the implementation of
proxies/factories may be subject to change. Plus there are corner cases,
where bridge methods are necessary. So that is a valid concern for the way
that some projects currently attempt reflection.

But is adding a generic signature to the synthetic method not an
independent problem issues from that? For anyone that picks up a reference
to that method (from the lambda or in whatever other way), the generic
information would be available, which would greatly help.

Greetings,
Stephan


On Mon, Jan 19, 2015 at 7:29 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>
> On 01/19/2015 04:18 PM, Joel Borggr?n-Franck wrote:
>
>> On 19 jan 2015, at 16:01, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>> On 01/19/2015 03:39 PM, Joel Borggr?n-Franck wrote:
>>>
>>>> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
>>>>>
>>>>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>>>>
>>>>>> the Java Reflection API allows to access the generic signature of
>>>>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>>>>> method. However, this is not yet supported for Lambda expressions.
>>>>>>
>>>>>> Given the following classes:
>>>>>>
>>>>>> class Tuple2<F0,F1> {
>>>>>>    F0 field0;
>>>>>>    F1 field1;
>>>>>>
>>>>>>    public Tuple2(F0 f0, F1 f1) {
>>>>>>      this.field0 = f0;
>>>>>>      this.field1 = f1;
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> interface Map<IN, OUT> {
>>>>>>    OUT map(IN in);
>>>>>> }
>>>>>>
>>>>>> Currently, there is no solution that allows to get further type
>>>>>> information about expressions like:
>>>>>>
>>>>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str,
>>>>>> 1);
>>>>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>>>>> information about the Tuple2's fields are always lost
>>>>>>
>>>>> map is a variable, so it doesn't have a return type.
>>>>>
>>>>> If map is a class variable or an instance variable, then
>>>>> Field#getGenericType should help.
>>>>>
>>>>> Expressions (including lambda expressions) aren't generally exposed
>>>>> through Core Reflection. If an expression (such as a lambda expression)
>>>>> happens to be implemented as a method, then relying on the [generic]
>>>>> signature of that method is dangerous since it may change from release to
>>>>> release.
>>>>>
>>>>>  One could argue that we should generate more attributes for synthetic
>>>> methods. We did for example add annotations to bridges [1]. While we do
>>>> want to it discourage depending on a specific translation strategy, I?m not
>>>> sure adding Signature will make more code break once/if we change
>>>> translation strategy.
>>>>
>>> The problem is not that adding a Signature will break, it's that these
>>> information will be not available
>>> anymore if we use a strategy based on one lambda proxy shared for
>>> several lambdas*
>>>
>> But isn?t this unrelated? I?m saying it might be reasonable to expect _a_
>> Signature for a generic method even if it is synthetic. To me it sounds
>> like that signature will be much less specific in your prototype, but it
>> can still exist?
>>
>
> err, sorry not clear,
> Yes, you're right, the signature will still exist but there will be no way
> at runtime to get a reference (in the generic sense) to the synthetic
> method. Because the link from a lambda proxy to the lambda implementation
> will be hidden.
>
>
>> cheers
>> /Joel
>>
>>
> cheers,
> R?mi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150124/0e31afbc/attachment.html>

From brian.goetz at oracle.com  Sun Jan 25 23:35:23 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 25 Jan 2015 18:35:23 -0500
Subject: Introduce a compiler option to store generic type information
	about a lambda expression using the Signature Attribute
In-Reply-To: <54AD550A.1050806@oracle.com>
References: <54AD4F24.2080605@apache.org> <54AD550A.1050806@oracle.com>
Message-ID: <54C57DBB.7040504@oracle.com>

There doesn't seem to be anything *wrong* with having a signature 
attribute on synthetic methods; the fact that we don't have them now is 
more an artifact of how erasure is implemented in the compiler than a 
deliberate decision to strip these methods of generic type information. 
  As we've seen in Project Valhalla, we've been bitten multiple times by 
missing generic information (which is missing for reasons that are 
effectively accidental.)  So I have no problem with the general idea of 
being more uniform about including generic signature attributes.

That said, the motivation that's been presented for adding them now is a 
pretty awful one.  I get why people want reflection to work over lambda 
instances, but that's not how reflection works -- reflection reflects 
over classes, not instances.  The current translation strategy happens 
to be one that, were this attribute there, would enable reflection to 
"accidentally work" to provide generic information, but this *will* 
change, at which point any reflection-based strategy falls apart (at 
which point people accuse of breaking their 
should-have-never-worked-in-the-first-place code.)


On 1/7/2015 10:47 AM, Maurizio Cimadamore wrote:
> Hi Timo,
> thanks for the patch - if I'm not mistaken, this would be the very first
> case in which a method marked with ACC_SYNTHETIC also gets a signature
> attribute. I will consult with the rest of the team and see if there's
> any objection.
>
> Cheers
> Maurizio
>
> On 07/01/15 15:22, Timo Walther wrote:
>> Hi all,
>>
>> the Java Reflection API allows to access the generic signature of
>> methods through the java.lang.reflect.Method#getGenericReturnType()
>> method. However, this is not yet supported for Lambda expressions.
>>
>> Given the following classes:
>>
>> class Tuple2<F0,F1> {
>>   F0 field0;
>>   F1 field1;
>>
>>   public Tuple2(F0 f0, F1 f1) {
>>     this.field0 = f0;
>>     this.field1 = f1;
>>   }
>> }
>>
>> interface Map<IN, OUT> {
>>   OUT map(IN in);
>> }
>>
>> Currently, there is no solution that allows to get further type
>> information about expressions like:
>>
>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str, 1);
>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>> information about the Tuple2's fields are always lost
>>
>> Especially data-intensive runtimes (like Apache Flink[0] where I am
>> working on) need as much type information as possible to be efficient.
>> Therefore, we searched for a way to also extract type information from
>> lambda expressions. Adding a generic signature to the generated
>> "lambda$XXX" static methods (at least by using a compiler option)
>> would be the perfect solution. It seems that the JVM Specification
>> does not prohibit such an implementation. An implementation of a later
>> extraction is described here[1].
>>
>> The Eclipse JDT compiler team is introducing a compiler option
>> "-genericsignature" with version 4.5 M4[2].
>>
>> I have implemented a patch prototype. It can be found at:
>> http://people.apache.org/~twalthr/patches/lambdaSignature.patch
>>
>> The patch postpones the type erasure of the lambda function's
>> parameters after the generic descriptor has been saved in a newly
>> introduced variable in MethodSymbol (if compiler option
>> "-lambdasignature" is set). The contents of the variable is read in
>> ClassWriter and written to method's Signature attribute in the
>> classfile. Tests are also included.
>>
>> No change to the class file format is required. The change is guarded
>> by a compiler option, so without that addition, nothing should behave
>> differently.
>>
>>
>> [0] http://flink.apache.org/
>> [1]
>> http://stackoverflow.com/questions/21887358/reflection-type-inference-on-java-8-lambdas
>>
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=449063
>>
>>
>> Regards,
>> Timo Walther
>

From maurizio.cimadamore at oracle.com  Thu Jan 29 12:49:18 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 29 Jan 2015 12:49:18 +0000
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54C137AB.6090404@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com> <54C0FC95.90807@oracle.com>
	<54C136B3.1070704@oracle.com> <54C137AB.6090404@oracle.com>
Message-ID: <54CA2C4E.4030700@oracle.com>

Ok - thx for the analysis - I'm ok with the original fix.

Maurizio

On 22/01/15 17:47, pooja chopra wrote:
> Hi Maurizio ,
>
> There is already a bug JDK-8057527 
> <https://bugs.openjdk.java.net/browse/JDK-8057527>: 
> tools/javac/innerClassFile/Driver.sh fails to cleanup files after it 
> because of which ' rm -rf src  ' piece of code was added so if we 
> remove this then again bug JDK-8057527 
> <https://bugs.openjdk.java.net/browse/JDK-8057527> will occur.
>
> Regards,
> Pooja
> On 1/22/2015 11:13 PM, pooja chopra wrote:
>> Hi Maurizio,
>>
>> In JDK 8  as I saw ' rm -rf src  '  line of code has been simply 
>> removed from the code  but  "src"  folder was temporarily created 
>> using 'mkdir src' in the Driver.sh code so I believe it should be 
>> removed if its created after use. Please suggest further .
>>
>> Regards,
>> Pooja
>> On 1/22/2015 7:05 PM, Maurizio Cimadamore wrote:
>>> It seems like the problematic rm in the last line has been removed 
>>> i.e. in JDK 8?
>>>
>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/2d2b2be57c78/test/tools/javac/innerClassFile/Driver.sh 
>>>
>>>
>>> Perhaps, instead of tweaking permission, we should just do things 
>>> the JDK 8 way?
>>>
>>> Maurizio
>>>
>>> On 12/01/15 07:04, pooja chopra wrote:
>>>> Hi All,
>>>> Please review below fix .
>>>>
>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>>> with exit code 1
>>>> Test bug fix.
>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>
>>>> Regards,
>>>> Pooja
>>>> On 12/5/2014 11:09 AM, pooja chopra wrote:
>>>>> Hi All,
>>>>> Gentle Reminder . Please review below fix .
>>>>>
>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>>>> with exit code 1
>>>>> Test bug fix.
>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>
>>>>> Regards,
>>>>> Pooja
>>>>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>>>>
>>>>>> Hello,
>>>>>> Please review a fix for the issue:
>>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh 
>>>>>> fails with exit code 1
>>>>>> Test bug fix.
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>>> The webrev is: 
>>>>>> http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>>
>>>>>> Thanks
>>>>>> Pooja
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150129/aabdf78f/attachment.html>

From pooja.chopra at oracle.com  Thu Jan 29 17:40:28 2015
From: pooja.chopra at oracle.com (pooja chopra)
Date: Thu, 29 Jan 2015 23:10:28 +0530
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54CA2C4E.4030700@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com> <54C0FC95.90807@oracle.com>
	<54C136B3.1070704@oracle.com> <54C137AB.6090404@oracle.com>
	<54CA2C4E.4030700@oracle.com>
Message-ID: <54CA708C.9070507@oracle.com>

Hi ,

Can the change mentioned in my webrev be submitted or we should wait for 
one more reviewer to review??

Regards,
Pooja
On 1/29/2015 6:19 PM, Maurizio Cimadamore wrote:
> Ok - thx for the analysis - I'm ok with the original fix.
>
> Maurizio
>
> On 22/01/15 17:47, pooja chopra wrote:
>> Hi Maurizio ,
>>
>> There is already a bug JDK-8057527 
>> <https://bugs.openjdk.java.net/browse/JDK-8057527>: 
>> tools/javac/innerClassFile/Driver.sh fails to cleanup files after it 
>> because of which ' rm -rf src  ' piece of code was added so if we 
>> remove this then again bug JDK-8057527 
>> <https://bugs.openjdk.java.net/browse/JDK-8057527> will occur.
>>
>> Regards,
>> Pooja
>> On 1/22/2015 11:13 PM, pooja chopra wrote:
>>> Hi Maurizio,
>>>
>>> In JDK 8  as I saw ' rm -rf src  '  line of code has been simply 
>>> removed from the code  but  "src"  folder was temporarily created 
>>> using 'mkdir src' in the Driver.sh code so I believe it should be 
>>> removed if its created after use. Please suggest further .
>>>
>>> Regards,
>>> Pooja
>>> On 1/22/2015 7:05 PM, Maurizio Cimadamore wrote:
>>>> It seems like the problematic rm in the last line has been removed 
>>>> i.e. in JDK 8?
>>>>
>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/2d2b2be57c78/test/tools/javac/innerClassFile/Driver.sh 
>>>>
>>>>
>>>> Perhaps, instead of tweaking permission, we should just do things 
>>>> the JDK 8 way?
>>>>
>>>> Maurizio
>>>>
>>>> On 12/01/15 07:04, pooja chopra wrote:
>>>>> Hi All,
>>>>> Please review below fix .
>>>>>
>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh fails 
>>>>> with exit code 1
>>>>> Test bug fix.
>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>> The webrev is: http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>
>>>>> Regards,
>>>>> Pooja
>>>>> On 12/5/2014 11:09 AM, pooja chopra wrote:
>>>>>> Hi All,
>>>>>> Gentle Reminder . Please review below fix .
>>>>>>
>>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh 
>>>>>> fails with exit code 1
>>>>>> Test bug fix.
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>>> The webrev is: 
>>>>>> http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>>
>>>>>> Regards,
>>>>>> Pooja
>>>>>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>> Please review a fix for the issue:
>>>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh 
>>>>>>> fails with exit code 1
>>>>>>> Test bug fix.
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>>>> The webrev is: 
>>>>>>> http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>>>
>>>>>>> Thanks
>>>>>>> Pooja
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150129/8ce10278/attachment-0001.html>

From sean.coffey at oracle.com  Thu Jan 29 17:43:48 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 29 Jan 2015 17:43:48 +0000
Subject: <Langtools> [7u] Review Request: JDK-8064454 Fix type in langtools
	for tools/javac/innerClassFile/Driver.sh
In-Reply-To: <54CA708C.9070507@oracle.com>
References: <5460EF0C.6090501@oracle.com> <54814528.7020501@oracle.com>
	<54B371F9.8020904@oracle.com> <54C0FC95.90807@oracle.com>
	<54C136B3.1070704@oracle.com> <54C137AB.6090404@oracle.com>
	<54CA2C4E.4030700@oracle.com> <54CA708C.9070507@oracle.com>
Message-ID: <54CA7154.20701@oracle.com>

Hi Pooja,

I think we're good to push your fix as it stands. Since we're past RDP2 
for 7u80, I'll work with you off list in resolving this one.

regards,
Sean.

On 29/01/2015 17:40, pooja chopra wrote:
> Hi ,
>
> Can the change mentioned in my webrev be submitted or we should wait 
> for one more reviewer to review??
>
> Regards,
> Pooja
> On 1/29/2015 6:19 PM, Maurizio Cimadamore wrote:
>> Ok - thx for the analysis - I'm ok with the original fix.
>>
>> Maurizio
>>
>> On 22/01/15 17:47, pooja chopra wrote:
>>> Hi Maurizio ,
>>>
>>> There is already a bug JDK-8057527 
>>> <https://bugs.openjdk.java.net/browse/JDK-8057527>: 
>>> tools/javac/innerClassFile/Driver.sh fails to cleanup files after it 
>>> because of which ' rm -rf src  ' piece of code was added so if we 
>>> remove this then again bug JDK-8057527 
>>> <https://bugs.openjdk.java.net/browse/JDK-8057527> will occur.
>>>
>>> Regards,
>>> Pooja
>>> On 1/22/2015 11:13 PM, pooja chopra wrote:
>>>> Hi Maurizio,
>>>>
>>>> In JDK 8  as I saw ' rm -rf src  '  line of code has been simply 
>>>> removed from the code  but  "src"  folder was temporarily created 
>>>> using 'mkdir src' in the Driver.sh code so I believe it should be 
>>>> removed if its created after use. Please suggest further .
>>>>
>>>> Regards,
>>>> Pooja
>>>> On 1/22/2015 7:05 PM, Maurizio Cimadamore wrote:
>>>>> It seems like the problematic rm in the last line has been removed 
>>>>> i.e. in JDK 8?
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/2d2b2be57c78/test/tools/javac/innerClassFile/Driver.sh 
>>>>>
>>>>>
>>>>> Perhaps, instead of tweaking permission, we should just do things 
>>>>> the JDK 8 way?
>>>>>
>>>>> Maurizio
>>>>>
>>>>> On 12/01/15 07:04, pooja chopra wrote:
>>>>>> Hi All,
>>>>>> Please review below fix .
>>>>>>
>>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh 
>>>>>> fails with exit code 1
>>>>>> Test bug fix.
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>>> The webrev is: 
>>>>>> http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>>
>>>>>> Regards,
>>>>>> Pooja
>>>>>> On 12/5/2014 11:09 AM, pooja chopra wrote:
>>>>>>> Hi All,
>>>>>>> Gentle Reminder . Please review below fix .
>>>>>>>
>>>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh 
>>>>>>> fails with exit code 1
>>>>>>> Test bug fix.
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>>>> The webrev is: 
>>>>>>> http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>>>
>>>>>>> Regards,
>>>>>>> Pooja
>>>>>>> On 11/10/2014 10:29 PM, pooja chopra wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>> Please review a fix for the issue:
>>>>>>>> 8064454 [TEST_BUG] Test tools/javac/innerClassFile/Driver.sh 
>>>>>>>> fails with exit code 1
>>>>>>>> Test bug fix.
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8064454
>>>>>>>> The webrev is: 
>>>>>>>> http://cr.openjdk.java.net/~kshefov/8064454/webrev.00/
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Pooja
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150129/6605549d/attachment.html>