JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters

Maurizio Cimadamore 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).

See:

https://docs.oracle.com/javase/specs/jls/se9/html/jls-9.html#jls-9.6.4.2

"if m has an element whose value is 
java.lang.annotation.RetentionPolicy.CLASS or 
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 
expression*."

Cheers
Maurizio
>
> 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?
>
> Thanks,
> Florian



More information about the jdk-dev mailing list