RFR[9]: 8147585: Annotations with lambda expressions has parameters result in wrong behavior.

[shilpi.rastogi at oracle.com]

Thanks Joseph!!
Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.05/

Regards,
Shilpi

On 6/7/2016 6:00 AM, Joseph D. Darcy wrote:
> Hello,
>
> The test
>
>   45     void testAnnotationWithLambda() {
>   46         Method[] methods = 
> AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods();
>   47         for (Method method : methods) {
>   48             assertEquals(1, method.getDeclaredAnnotations().length);
>   49         }
>   50     }
>
> is very non-specific in what it is testing. A better test would 
> include something like
>
>     method.isAnnotationPresent(@LambdaWithParameter) &&
>     method.isAnnotationPresent(@LambdaWithouParameter)
>
> if both annotations were put on the same method.
>
> Cheers,
>
> -Joe
>
> On 6/6/2016 12:20 AM, shilpi.rastogi at oracle.com wrote:
>> Gentle reminder!!
>>
>> On 6/3/2016 11:40 AM, shilpi.rastogi at oracle.com wrote:
>>> Thanks Vladimir and Joel!!
>>> Please see http://cr.openjdk.java.net/~srastogi/8147585/webrev.04/
>>> Added restriction for synthetic methods as well.
>>>
>>> On 6/2/2016 5:04 PM, Vladimir Ivanov wrote:
>>>>
>>>>
>>>> On 6/2/16 12:02 AM, Joel Borggrén-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> I think this was caught by the verifier before 8 since you 
>>>>> couldn't have
>>>>> concrete or private methods in an interface. Now you can (though 
>>>>> not in
>>>>> Java for private ones).
>>>>>
>>>>> My spider sense tells me there might be something lurking here 
>>>>> (though
>>>>> it was a while since this was in my L1 cache). It is not likely, 
>>>>> but I'm
>>>>> not 100% sure that it is impossible to make javac produce a bridge 
>>>>> when
>>>>> compiling an annotation type for example, so why not remove synthetic
>>>>> methods as well?
>>>>
>>>> I'm not an expert in annotation processing, but it bothers me as 
>>>> well, since current behavior looks too Java-centric. There are 
>>>> valid (in JVMS sense) class files which are not produced by javac 
>>>> or from java source file.
>>>>
>>>> What is expected behavior in such case? It is unfortunate when 
>>>> non-Java languages have to obey to Java rules. It reminds me a 
>>>> problem with Class.getSimpleName() (see JDK-8057919 [1]) we fixed 
>>>> some time ago.
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8057919
>>>>
>>>>>
>>>>> Spending some time with ASM to do a bunch of tests not compilable in
>>>>> java might be useful, there should also be some frameworks in 
>>>>> langtools
>>>>> to produce invalid classfiles IIRC.
>>>   Raised https://bugs.openjdk.java.net/browse/JDK-8158510 to include 
>>> new test cases.
>>>
>>> Regards,
>>> Shilpi
>>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>>> On Tue, 31 May 2016 at 17:49 shilpi.rastogi at oracle.com
>>>>> <mailto:shilpi.rastogi at oracle.com> <shilpi.rastogi at oracle.com
>>>>> <mailto:shilpi.rastogi at oracle.com>> wrote:
>>>>>
>>>>>     Thanks Paul!!
>>>>>     Please see 
>>>>> http://cr.openjdk.java.net/~srastogi/8147585/webrev.03/
>>>>>
>>>>>     Thanks,
>>>>>     Shilpi
>>>>>
>>>>>     On 5/31/2016 7:57 PM, Paul Sandoz wrote:
>>>>>     > >"Returns an array containing Method objects reflecting all the
>>>>>     declared methods of the class or interface represented by this 
>>>>> Class
>>>>>     object, including public, protected, default (package) access, 
>>>>> and
>>>>>     private methods, but excluding inherited methods."
>>>>>
>>>
>>
>