Broken example in spec ?

[Maurizio Cimadamore]

On 10/02/13 04:10, Srikanth S Adayapalam wrote:
> I think this part needs a careful relook - Both javac 8b74 and eclipse
> refuse to compile this snippet*precisely*  for the reason that certain
> parameterization could run into unrelated  return types.
> Ergo, `Functional' is not even a legal interface - let alone a functional
> interface.
I agree that Functional<String, Integer> is ill formed, as it inherits 
two methods that are override-equivalent signatures, but where neither 
overrides the other.

I think the point here is - should the functional interface definition 
be allowed in contexts where an error can occur? One could imagine an 
instantiation like this:

Functional<Integer, Integer>, or Function<Integer, Number>

which would lead to a well-formed interface. And functional, too (as all 
methods can be implemented at once).

On the other hand, I believe that some time ago we pushed back on the 
notion of making functional interface definition a property of types, 
which, as you example demonstrates, often leads to obscure semantics; 
and we aimed at an approach where functional interface is a a property 
of class declarations (hence the possibility of using an annotation).

This is probably a case in which the definition needs to be dumbed down 
a little in order to take into account some form of class/interface 
well-formedness.

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20130211/39ab5b9d/attachment.html