Request for review: proposal for @FunctionalInterface checking

[Joe Darcy]

On 12/28/2012 12:36 PM, Kevin Bourrillion wrote:
> (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.

FWIW, part of adding this annotation type to the JDK would be annotating 
the affected platform interfaces so that is a cost we value as 
appropriate for the code base.

-Joe

>
>
> On Fri, Dec 28, 2012 at 12:30 PM, Kevin Bourrillion <kevinb at google.com 
> <mailto: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 <mailto: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 <mailto: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 <mailto:kevinb at google.com>
>
>
>
>
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com 
> <mailto:kevinb at google.com>