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

[Joseph D. Darcy]

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."
>>>>
>>
>