Perché il compilatore Java non può inferire correttamente l'ereditarietà?

Question

risposta si riduce a Java does not support lower bounds on parameterized methods, because such a feature is "not useful enough", fare riferimento a un similar question

Dato il seguente frammento:

package demo; 

public class Demo { 
    interface Foo { void foo(); } 
    interface Bar { void bar(); } 
    interface FooBar { 
     <R extends Foo & Bar> R foobar(); 

     static FooBar create() { return new TypicalJavaFooBar(); } 
    } 

    private static final class TypicalJavaFooBar implements Foo, Bar, FooBar { 
     public void bar() { System.out.println("foo"); } 
     public void foo() { System.out.println("bar"); } 

     public <R extends Foo & Bar> R foobar() { 
      return (R) this; 
     } 
    } 

    public static void main(String[] args) { 
     FooBar x = FooBar.create(); 
     Foo foo = x.foobar(); 
     Bar bar = x.foobar(); 
     x.foobar().foo(); 
     x.foobar().bar(); 
    } 
} 

Senza il cast esplicito a R in TypicalJavaFooBar#foobar compilatore non riesce con il seguente errore

Error:(13, 20) java: incompatible types: demo.Demo.TypicalJavaFooBar cannot be converted to R

mio la domanda è perché? Per me, sembra che il compilatore debba avere abbastanza informazioni dal TypicalJavaFooBar è chiaramente definito per implementare sia Foo e Bar; perché non è sufficiente per soddisfare il vincolo Foo & Bar?

UPDATE

L'obiettivo principale di questo esercizio è quello di definire il seguente contratto: metodo foobar invitando un'istanza di un FooBar è garantito per tornare qualcosa che implementa sia Foo e Bar.

Answer 1

Il tipo di parametro R è legato al metodo dal codice chiamante e potrebbe teoricamente essere Baz implements Foo, Bar; vedere, ad esempio, Collections.emptySet(), il cui parametro di tipo è determinato dal chiamante e può essere influenzato da un tipo di testimone.

Per fare ciò che si sta tentando apparentemente, è necessario spostare il parametro di tipo sull'interfaccia FooBar e disporre di TypicalJavaFooBar implements Foo, Bar, FooBar<TypicalJavaFooBar>.

Answer 2

tuo R può essere di qualsiasi tipo, che è un Foo & Bar in modo da poter scrivere

class MyFooBar implements Foo, Bar { ... 


FooBar x = new TypicalJavaFooBar(); 
MyFooBar mfb = x.foobar(); // this compiles now with the cast. 

Answer 3

No, il compilatore non può inferenza del tipo di R ed il cast è sbagliato. capire perché, basta estendere la classe come questa:

static class C extends TypicalJavaFooBar { 

    void eat() {} 

    @Override 
    public void bar() {} 

    @Override 
    public void foo() {} 
} 

Poi, il cast permette questo:

FooBar x = new TypicalJavaFooBar(); 
C c = x.foobar(); 
c.eat(); 

che si traduce in un RuntimeException:

Exception in thread "main" java.lang.ClassCastException: demo.Demo$TypicalJavaFooBar cannot be cast to demo.Demo$C 

Questo è il motivo - - sicuramente i progettisti del compilatore non lo permetterebbero. C'è qualcosa di sbagliato nel codice, da cui la necessità del cast.

Answer 4

Se si potrebbe usare questo in Java

if (obj instanceof (Foo & Bar)) 

allora non sarebbe stato costretto a fare il cast.