JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters
maurizio.cimadamore at oracle.com
Tue Jan 30 13:27:32 UTC 2018
On 30/01/18 09:21, Florian Weimer wrote:
> On 01/26/2018 04:08 PM, Maurizio Cimadamore wrote:
>> * the second reason, which was pointed out correctly in the email, is
>> to provide a path to add modifiers (such as 'final') and or
>> annotations to a lambda parameter w/o the need of resorting to
>> explicit types.
> I would love to see some more discussion how you plan to add
> annotation support without reifying the lambda. There was a recent
> discussion about the lack of generic type information for lambdas, and
> people didn't want to add this. Why would we do essentially the same
> thing for annotations?
I didn't suggest we should have additional support for annotations.
That said, lambda parameters CAN be annotated today, only, the
annotations are not guaranteed to survive until runtime. This is good
enough for static tools (annotation processors) that need to consume
such annotations (as said in my previous message), but not good enough
for frameworks which need to reflectively inspect such annotations at
runtime. This JEP in no way changes the status quo w.r.t. annotation
support. It simply doesn't force you to put in an explicit type, should
you really want to annotate a lambda parameter (knowing the limitations
that annotated lambda parameters have).
"if m has an element whose value is
java.lang.annotation.RetentionPolicy.RUNTIME, then a Java compiler must
ensure that a is represented in the binary representation of the class
or interface in which a appears, *unless a annotates a local variable
declaration or a annotates a formal parameter declaration of a lambda
> On this thread, it has been suggested that the annotation on the
> lambda parameter would instead be applied to the type parameter of a
> generic type. Was this an oversight, or is this expected to be part
> of a future design?
More information about the jdk-dev