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

[Michael Haupt]

Hi Shilpi,

I will be happy to sponsor the push.

Best,

Michael

> Am 07.06.2016 um 11:39 schrieb 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."
>>>>>> 
>>>> 
>>> 
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment