Annotating lambda expressions

Alex Buckley alex.buckley at
Fri Jul 10 22:03:23 UTC 2015

OK, but it's precisely the fact that inner classes are declarations that 
allows them to be annotated, because for declarations we specify the 
binary name, membership, and other artifacts of translation. No such 
spec for the translation of expressions (or statements) -- and I think 
it's generally regarded as a feature-not-a-bug that compilers have great 
freedom in translating lambda expressions.


On 7/10/2015 2: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.
> Ron Pressler
> <>
> @puniverseco <> on Twitter
> On Fri, Jul 10, 2015 at 10:38 PM, Alex Buckley <alex.buckley at
> <mailto:alex.buckley at>> wrote:
>     On 7/10/2015 2:31 AM, Maurizio Cimadamore wrote:
>         On 10/07/15 09:43, Ron Pressler wrote:
>             (Related to
>             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

More information about the compiler-dev mailing list