JDK 8 code review request for 8005298 Add FunctionalInterface type to the core libraries

Remi Forax forax at univ-mlv.fr
Thu Jan 17 07:00:24 UTC 2013

On 01/16/2013 05:09 PM, Brian Goetz wrote:
> 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.

so we agree,
like @Override, the retention of this annotation should be SOURCE.


> 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

More information about the core-libs-dev mailing list