The point is not to provide an ironclad guarantee that SAM conversion will never fail. It is to capture the original author's design intent and provide a small amount of compile-time tooling to help enforce that. Like @Override.
On Jan 16, 2013, at 2:21 AM, Remi Forax wrote: > On 01/16/2013 10:51 AM, Florian Weimer wrote: >> On 01/16/2013 07:54 AM, Joe Darcy wrote: >>> Hi Florian, >>> >>> On 1/10/2013 1:23 AM, Florian Weimer wrote: >>>> On 01/08/2013 10:24 PM, Joe Darcy wrote: >>>>> As discussed over on one of the Project Lambda lists [1], we're adding >>>>> an interface type to the platform to explicitly mark interface types as >>>>> being functional interfaces suitable for use in lambda expressions. >>>>> Please review the addition of this new type: >>>>> >>>>> http://cr.openjdk.java.net/~darcy/8005298.0/ >>>> >>>> Shouldn't this annotation have @Retention(RetentionPolicy.SOURCE), >>>> similar to the @Override annotation? >>> >>> No; we intentionally made this annotation have runtime retention to >>> allow it to also be queried to various tools at runtime, etc. >> >> This is really a bit odd. Doesn't this risk that code will rely on the >> annotation, instead of inferring the functional interface status based on >> the interface contents? > > Yes, it's a serious issue IMO. > because the annotation is verified at compile time and the linking is done at > runtime in Java so the annotation can be present and valid when compiled but > at runtime the interface is not a functional interface anymore because by > example a super interface was recompiled without compiling the annotated > interface. > > I agree that a good way to mitigate this is to make the annotation not > present in the bytecode and only available to javac and all annotation > processors. > If a runtime tool want this information, it should use the reflection API > that provides the VM point of view of the world, not the compiler(s) one. > >> >> I could not find this part in the lambda-libs-spec-experts discussion. Have >> you got a more specific pointer? >> > > As far as I now, this part was not discussed. > For reference, the whole thread starts here: > http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-December/000877.html > > Rémi >
