Broken example in spec ?
maurizio.cimadamore at oracle.com
Mon Feb 11 03:50:11 PST 2013
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lambda-spec-experts