(original) (raw)
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@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@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@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
\--