Perché Java impone la compatibilità del tipo restituito per i metodi statici sottoposti a override?

Question

Per this answer e this answer, i metodi statici Java non sono virtuali e non possono essere sovrascritti. Intuitivamente, quindi, questo dovrebbe funzionare (anche se nel 99% dei casi si tratta di programmazione pericoloso):

class Foo 
{ 
    public static String frob() { 
     return "Foo"; 
    } 
} 

class Bar extends Foo 
{ 
    public static Number frob() { 
     return 123; 
    } 
} 

Tuttavia, in pratica, questo si ottiene:

Foo.java:10: frob() in Bar cannot override frob() in Foo; attempting to use incompatible return type 
found : java.lang.Number 
required: java.lang.String 
    public static Number frob() { 
         ^

Ingenuamente, sembra che Foo.frob() e Bar.frob() non dovrebbe avere nulla a che fare l'uno con l'altro; ma Java insiste che lo facciano. Perché?

(Nb:. Non voglio sentire perché sarebbe una cattiva idea per codificare in questo modo, voglio sentire che cosa è in Java e/o la progettazione JVM che rende questa restrizione necessario)

---

aggiornato per aggiungere: per coloro che pensano che il compilatore sta per confondersi chiamando metodi statici sulle istanze, se si consente questo: non lo farà. Ha già di capire questo nel caso in cui il metodo firme sono compatibili:

class Foo 
{ 
    static String frob() { 
     return "Foo"; 
    } 
} 

class Bar extends Foo 
{ 
    static String frob() { 
     return "Bar"; 
    } 
} 

class Qux { 
    public static void main(String[] args) { 
     Foo f = new Foo(); 
     Foo b = new Bar(); 
     Bar b2 = new Bar(); 

     System.out.println(f.frob()); 
     System.out.println(b.frob()); 
     System.out.println(b2.frob()); 
    } 
} 

si ottiene:

Foo 
Foo 
Bar 

La domanda è: qual è la ragione concreta per cui non poteva come facilmente (nel caso incompatibili firme) ottenere:

Foo 
Foo 
123 

Answer 1

si consideri il seguente:

public class Foo { 
    static class A { 
    public static void doThing() { 
     System.out.println("the thing"); 
    } 
    } 

    static class B extends A { 

    } 

    static class C extends B { 
    public static void doThing() { 
     System.out.println("other thing"); 
    } 
    } 

    public static void main(String[] args) { 
    A.doThing(); 
    B.doThing(); 
    C.doThing(); 
    } 
} 

Esegui! Compila e stampa

the thing 
the thing 
other thing 

metodi statici sorta di ereditano - nel senso che B.doThing si traduce in una chiamata a A.doThing - e possono sorta di essere sovrascritto.

Sembra che fosse principalmente una chiamata di giudizio per il JLS. Il modo più specifico in cui JLS sembra risolvere questo problema è section 8.2, che semplicemente non dice che i metodi statici non sono ereditati da.

Answer 2

È perché in Java, un metodo particolare è chiamato in base al tipo di tempo di esecuzione dell'oggetto e non al tipo di tempo di compilazione di esso. Tuttavia, i metodi statici sono metodi di classe e quindi l'accesso ad essi viene sempre risolto durante la compilazione utilizzando solo le informazioni sul tipo di tempo di compilazione. Cioè, che cosa accadrebbe se si potesse compilare il codice di cui sopra e l'utilizzo come questo

Foo bar = new Bar(); 
bar.frob(); 

Answer 3

JLS 8.4.2 Method Signature, brevemente:

due metodi hanno la stessa firma se hanno lo stesso nome e argomenti tipi.

Non si dice nulla di staticità.I metodi statici possono essere richiamati tramite un'istanza (o un riferimento null): come deve essere risolto il metodo se si fa riferimento a una sottoclasse tramite una dichiarazione della superclasse?

Answer 4

Bene, la JVM potrebbe probabilmente essere fatta per permetterlo, ma parliamo del perché è una pessima idea dal punto di vista del compilatore.

I dati di istanza (incluso il tipo di istanza) non è qualcosa che è un semplice problema da risolvere in fase di compilazione. Ovviamente è ben noto in fase di runtime. Se ho una barra variabile di tipo Bar, e chiamo s = bar.frob(), il compilatore dovrebbe decodificare la barra dei tipi per vedere se il valore restituito è accettabile. Se determinare il tipo in fase di compilazione è un problema molto difficile, ciò rende il compilatore inefficiente nella migliore delle ipotesi. Nel peggiore dei casi la risposta è errata e si verificano errori di runtime che dovrebbero essere stati rilevati in fase di compilazione.