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

[Vladimir Ivanov]

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