Broken example in spec ?

[Dan Smith]

Looks to me like the JLS and javac/Eclipse are out of sync on the definition of "return-type-substitutability" (JLS 8.4.5).  If this is longstanding, accepted implementation behavior, we could probably adjust the JLS text to accommodate.  I'll investigate further.

—Dan

On Feb 9, 2013, at 9:10 PM, Srikanth S Adayapalam <srikanth_sankaran at in.ibm.com> wrote:

> 0.6.1 - 9.8, Discussion & motivation box, second bullet says: 
> 
> // --------8< ----------------- 
> 
> 
> Under the current definition, a functional interface may be parameterized in a way that produces distinct abstract methods—that is, multiple methods that cannot be legally overridden with a single declaration. For example:
> interface I { Object m(); }
> interface J<S> { S m(); }
> interface K<T> { T m(); }
> interface Functional<S,T> extends I, J<S>, K<T> {}
> 
> Interface Functional is functional—I.m is return-type-substitutable for the other two—but Functional<String,Integer> clearly cannot be implemented with a single method. This situation is acceptable, however: when functional interfaces are implicitly implemented, the overriding effectively occurs generically; instantiation of type parameters only occurs at the use site. In other words, if a lambda expression represents a Functional<String,Integer>, its treatment is similar to that of the following:
> 
> class FunctionalImpl<S,T> implements Functional<S,T> { ... }
> Functional<String,Integer> f = new FunctionalImpl<String,Integer>();
> 
> // --------8< ----------------- 
> 
> 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. 
> 
> Let me know if I have missed some nuance here. 
> 
> Thanks! 
> Srikanth.