Request for review: proposal for @FunctionalInterface checking

[Kevin Bourrillion]

(And yes, I understand the bits about action-at-a-distance and
documentation value. @Override has those too but *also* so much more value;
this doesn't. That still puts it in the same category as most of JSR 305.)

Btw what are the costs of adding this annotation?

   - One more thing to learn, making lamdas seem some tiny percentage more
   complicated
   - Great potential for user misconception (that it's required), but
   little harm should come of that
   - Companies like mine have one more thing to add to our internal style
   guides (can we use it, should we use it, must we use it?)

The only costs I see are pretty small.  However, the benefit also looks
extremely small to me, and I continue to think it just doesn't quite seem
to belong.


On Fri, Dec 28, 2012 at 12:30 PM, Kevin Bourrillion <kevinb at google.com>wrote:

> I see one important difference from @Override.  @Override catches errors
> that might otherwise go completely uncaught.  With a type intended to be a
> functional interface, the moment anyone ever tries to use it as such,
> there's your compilation error.
>
> So I don't see what sets @FunctionalInterface apart from the whole host of
> static-analysis annotations that we've relegated to the now-abandoned JSR
> 305.
>
>
> On Fri, Dec 28, 2012 at 12:17 PM, Brian Goetz <brian.goetz at oracle.com>wrote:
>
>> Yes.  If you mark an interface as functional, and it is not, the compiler
>> will warn/error.  This prevents action-at-a-distance errors where you have
>> a SAM, other code depends on its SAM-ness, and someone later decides to add
>> another abstract method (or a method to one of its supertypes).  It also
>> provide extra documentation value.
>>
>> Basically, just like @Override.
>>
>>
>> On 12/28/2012 3:16 PM, Sam Pullara wrote:
>>
>>> Is the intent that an interface that is not functional but marked as
>>> such won't compile?
>>>
>>> Sam
>>>
>>> On Dec 28, 2012, at 3:12 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>
>>>  Note that this proposal does NOT intend to change the rule that
>>>> functional interfaces are recognized structurally; single-method interfaces
>>>> will still be recognized as SAMs.  This is more like @Override, where the
>>>> user can optionally capture design intent and the compiler can warn when
>>>> said design intent is violated.
>>>>
>>>> I support this proposal.
>>>>
>>>> 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
>>>>>
>>>>>
>>>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com