Request for review: proposal for @FunctionalInterface checking (original) (raw)

Remi Forax forax at univ-mlv.fr
Thu Jan 3 02:52:26 PST 2013

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 { ... } the annotation could capture the parameter and return types as well: @FunctionalInterface(return = boolean.class, params = { Object.class }) interface Predicate { ... } (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 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 functional interface 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 not 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:

  • The type is an interface type and not an annotation type, enum, or
    •  class.
  • The annotated type satisfies the requirements of a functional
    •  interface. @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

    More information about the lambda-libs-spec-observers mailing list