Annotating lambda expressions

[Remi Forax]

On 07/10/2015 11:41 PM, Ron Pressler wrote:
> I see no problem with cast annotations not being retrievable via 
> straightforward reflection just as I see no problem annotating the 
> generated method (which should always exist /somewhere/): in both 
> cases, those annotations are intended for use by tools that analyze 
> the entire project's source/bytecode (e.g. for 
> typechecking/instrumentation) rather than by specific reflective queries.
>
> What bothers me is that a capability that was trivial with inner 
> classes is now lost when using lambdas.

you can easily add a pattern recognizable by source/bytecode tools to do 
what you want,
let suppose you have a static method like this:
   static <T> T annotate(Class<? extends Annotation> annotation, T 
lambda) { return lambda; }

to annotate a lambda, your example can be written like this:
   foo(annotate(Special.class, () -> { ...}))

in the bytecode it will be translated to something like this:
   ldc Special.class
   invokedynamic ()Runnable
     LambdaMetafactory  + method handle ref on the lambda body
   invokestatic Bar.annotate(Class, Object)Object
   checkcast Runnable
   invokevirtual Baz.foo(Runnable)...

which is easy to recognize.

>
> Ron Pressler
> paralleluniverse.co <http://paralleluniverse.co/>
> @puniverseco <https://twitter.com/puniverseco> on Twitter

Rémi

>
> On Fri, Jul 10, 2015 at 10:38 PM, Alex Buckley 
> <alex.buckley at oracle.com <mailto:alex.buckley at oracle.com>> wrote:
>
>     On 7/10/2015 2:31 AM, Maurizio Cimadamore wrote:
>
>         On 10/07/15 09:43, Ron Pressler wrote:
>
>             (Related to
>             http://mail.openjdk.java.net/pipermail/compiler-dev/2015-January/009220.html)
>
>             It is useful to add an annotation to a lambda expression
>             -- as in
>             foo(@Special () -> { ...}) -- which will be applied to the
>             static
>             method implementing the lambda (not to the interface the
>             lambda
>             implements). This would allow instrumentation tools
>             operating on
>             method implementations to handle lambdas. So far, AFAICT,
>             this is not
>             possible (or am I wrong?).
>
>         This is not possible, currently - as Remi said; you have
>         annotations on
>         declarations (i.e. variable, classes, methods) - you have
>         annotation on
>         types (i.e. type of a cast, type argument, etc.) - but you
>         don't have
>         annotations on _expressions_.
>         I take it that, under the current translation scheme, there
>         seems to be
>         a plausible description for what should happen when the lambda is
>         annotated; but what if the lambda is turned into a method
>         reference (by
>         some IDE refactoring, or human intervention) ? In that case it
>         is not
>         guaranteed that there would still be a physical place where to
>         put the
>         annotation (unless we tell the compiler to 'expand' all
>         annotated method
>         references).
>
>
>     Yes, the problem with annotations-on-expressions is not the
>     language grammar but the storage of the annotations in the class
>     file. With no standard way of translating source expressions to
>     bytecode, there can be no standard API for retrieving
>     annotations-on-expressions from bytecode. More broadly, there has
>     never been a standard reflective API capable of inspecting method
>     bodies.
>
>     This explains why JSR 308 stayed away from
>     annotations-on-expressions -- we were not in a position to let
>     them be read back. It was already bad enough that some
>     annotations-on-types are stored in the class file at the level of
>     individual bytecodes (e.g. an annotation on the type of a cast) so
>     are not retrievable by any standard reflective API.
>
>     Alex
>
>

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