@FunctionalInterface implications

Remi Forax forax at univ-mlv.fr
Sat Nov 23 03:17:53 PST 2013

On 11/23/2013 02:32 AM, Brian Goetz wrote:
> Function is extended by BinaryOperator, also a functional interface,
> which specializes its type parameters.  I think that's a fine pattern.

I don't want to restart the thread about the naming of UnaryOperator and 
but  BinaryOperator is a BiFunction not a Function, UnaryOperator is a 

BTW I've recently discover something weird, Function.identity() should 
return a UnaryOperator<T> and not a Function<T,T> which can be seen as 
an hint of the fact that having two interfaces for something so similar 
is not a good idea.

I think we have missed a point when we have discussed about naming, the 
real question is why UnaryOperator and BinaryOperator exist, from now, 
they does not seem to worth their weight (naming, specialization, etc) ?


> More generally, its perfectly fine for an interface to extend a
> functional interface but not itself be a functional interface.  See
> Node.Builder inside the Stream package, for example.
> On 11/22/2013 7:50 PM, Richard Warburton wrote:
>> Hi,
>> If the intent of an interface marked with @FunctionalInterface is to be
>> used as such then should it ever be extended by another interface?
>> I appreciate there are probably enough complex interactions that generating
>> a compile error if this happens would be too restrictive but what about
>> 'morally' or as a guideline?
>> regards,
>>     Richard Warburton
>>     http://insightfullogic.com
>>     @RichardWarburto <http://twitter.com/richardwarburto>

More information about the lambda-dev mailing list