Request for review: proposal for @FunctionalInterface checking

[Remi Forax]

On 01/02/2013 09:29 PM, Joe Darcy wrote:
> On 1/2/2013 11:13 AM, Brian Goetz wrote:
>> In Doug's "tyranny of function names", there was an appeal for a 
>> known, regularized naming convention:
>>
>>>  Using anything other than a known regularized naming scheme
>>> in libraries will make it impossible to ever take advantage of
>>> language-based function type support.
>>
>> Perhaps @FunctionalInterface can be extended to provide this. Instead 
>> of just
>>
>> @FunctionalInterface
>> interface Predicate<T> { ... }
>>
>> the annotation could capture the parameter and return types as well:
>>
>> @FunctionalInterface(return = boolean.class,
>>                      params = { Object.class })
>> interface Predicate<T> { ... }
>>
>> (or better, some scheme that lets us encode generic signatures rather 
>> than erased ones).
>
> Hmmm.  I think trying to use an annotation in this way would be very 
> awkward and error prone since we'd  basically be asking people to 
> generate an (erased?) signature by hand.
>
> -Joe

Or to let IDE do that, it's not far from generating a kind of serial 
UID, a functional interface UID for the interface and checks if the 
functional descriptor match the UID or not.

I'm still not sure @FunctionalInterface is a good idea at all.

Rémi

>
>>
>> Then we're making a clear statement that "Predicate<T> is a 
>> functional interface with type signature T->boolean", which would 
>> open the door to future loosenings in a less ad-hoc way?
>>
>> Doug, does this help at all?
>>
>> On 12/28/2012 3:02 PM, Joe Darcy wrote:
>>> Hello,
>>>
>>> We've had some discussions internally at Oracle about adding a
>>> FunctionalInterface annotation type to the platform and we'd now 
>>> like to
>>> get the expert group's evaluation and feedback on the proposal.
>>>
>>> Just as the java.lang.Override annotation type allows compile-time
>>> checking of programmer intent to override a method, the goal for the
>>> FunctionalInterface annotation type is to enable analogous compile-time
>>> checking of whether or not an interface type is functional. Draft
>>> specification:
>>>
>>> package java.lang;
>>>
>>> /**
>>> Indicates that an interface type declaration is intended to be a
>>> <i>functional interface</i> as defined by the Java Language
>>> Specification.  Conceptually, a functional interface has exactly one
>>> abstract method.  Since default methods are not abstract, any default
>>> methods declared in an interface do not contribute to its abstract
>>> method count.  If an interface declares a method overriding one of the
>>> public methods of java.lang.Object, that also does <em>not</em> count
>>> toward the abstract method count.
>>>
>>> Note that instances of functional interfaces can be created with lambda
>>> expressions, method references, or constructor references.
>>>
>>> If a type is annotated with this annotation type, compilers are 
>>> required
>>> to generate an error message unless:
>>>
>>> <ul>
>>> <li> The type is an interface type and not an annotation type, enum, or
>>> class.
>>> <li> The annotated type satisfies the requirements of a functional
>>> interface.
>>> </ul>
>>>
>>> @jls 9.8 Functional Interfaces
>>> @jls 9.4.3 Interface Method Body
>>> @jls 9.6.3.8 FunctionalInterface  [Interfaces in the java.lang package
>>> get a corresponding JLS section]
>>> @since 1.8
>>> */
>>> @Documented
>>> @Retention(RUNTIME)
>>> @Target(TYPE)
>>> @interface FunctionalInterface {} // Marker annotation
>>>
>>> Annotations on interfaces are *not* inherited, which is the proper
>>> semantics in this case.  A subinterface of a functional interface can
>>> add methods and thus not itself be functional.  There are some
>>> subtleties to the definition of a functional interface, but I thought
>>> that including those by reference to the JLS was sufficient and putting
>>> in all the details would be more likely to confuse than clarify.
>>>
>>> Please send comments by January 4, 2013; thanks,
>>>
>>> -Joe
>>>
>