Nome variabile della modifica Java modifica il comportamento del programma

Question

Ho trovato uno scenario in cui il programma java si comporta diversamente dopo la ridenominazione di una variabile. Capisco che questo non sia in realtà un codice che chiunque userebbe, ma se qualcuno sa che cosa sta succedendo sarebbe bello avere una spiegazione. Ho provato questo con java 1.6 su Eclipse Kepler.

package _test; 

public class TestClass{ 
    public static void main(String...args){ 
     Object testClazz$1 = new Object(){ 
      public String toString() { 
       return "hello"; 
      } 
     }; 
     TestClass$1 test = new TestClass$1(); 
     System.out.println(testClazz$1.toString()); 
     test.doStuff(); 
    } 
} 

class TestClass$1{ 
    public void doStuff(){ 
     System.out.println("hello2"); 
    } 
} 

Questo uscite:

hello

Exception in thread "main" java.lang.NoSuchMethodError: _test.TestClass$1.doStuff()V at _test.TestClass.main(TestClass.java:13)

Per quanto ho capito il compilatore crea un file TestClass $ 1.class per l'oggetto testClazz $ 1 e questo fa sì che una collisione di denominazione.

Ma dopo la ridenominazione dell'oggetto da TestClass $ 1:

package _test; 

public class TestClass{ 
    public static void main(String...args){ 
     Object testClass$1 = new Object(){ 
      public String toString() { 
       return "hello"; 
      } 
     }; 

     TestClass$1 test = new TestClass$1(); 
     System.out.println(testClass$1.toString()); 
     test.doStuff(); 
    } 
} 

class TestClass$1{ 
    public void doStuff(){ 
     System.out.println("hello2"); 
    } 
} 

l'output è:

_test.TestClass$1@2e6e1408

hello2

Tutte le idee che cosa sta succedendo qui?

Answer 1

Quando il classloader incontra la classe anonima Object() {...}, la carica sotto il nome TestClass$1. Ciò crea un conflitto con class TestClass$1 {...} che è stato definito in modo esplicito.

Tuttavia, i conflitti dei nomi di classe vengono gestiti in modo non vergognoso.This bit of documentation ci dice che

If the class c has already been linked, then this method simply returns.

Questo è ciò che accade nel vostro caso. È sempre possibile caricare solo una delle due classi TestClass$1.

I "diversi nomi di variabili" sono non responsabile di qualcosa di diverso da ri-compilazione e ri-linking all'interno del vostro compilatore. A questo punto, il classloader è libero di scegliere quale dei due TestClass$1 piace e lo usa ovunque.

---

Se stai usando qualcosa come Eclipse (come me) e poi il bytecode otterrà cache, fino a quando una nuova touch operazione sul file sorgente (e l'aggiornamento del timestamp ...). Ecco che cosa ho fatto di riprodurre (in esecuzione OpenJDK 1.7, Eclipse Keplero sotto RedHat):

Mettere questo all'interno di un file sorgente TestClass.java:

package javaclasses.classes; 

public class TestClass{ 
    public static void main(String...args){ 
     Object o = new Object(){ 
      public String toString() { 
       return "hello"; 
      } 
     }; 

     TestClass$1 test = new TestClass$1(); 
     System.out.println(o.toString()); 
     test.doStuff(); 
    } 
} 

class TestClass$1{ 
    public void doStuff(){ 
     System.out.println("hello2"); 
    } 
} 

ctrl + F11 uscite:

javaclasses.classes.TestClass$1@42293b53 
hello2 

Aprire questo in una console e touch TestClass.java

Torna in Eclipse e Ctrl + F11 ora uscite:

hello 
Exception in thread "main" java.lang.NoSuchMethodError: javaclasses.classes.TestClass$1.doStuff()V 
    at javaclasses.classes.TestClass.main(TestClass.java:13) 

---

Conlusion: Tutto ciò che si può dire in via definitiva è che il ClassLoader di default non è affidabile per risolvere manualmente le classi con lo stesso completo nomi. Cambiare i nomi delle variabili non ha importanza, la data/ora aggiornata sul tuo file sorgente lo fa.

Answer 2

Le classi anonime sono denominate automaticamente aggiungendo un numero $ e un numero crescente al nome della classe che le include.

Nel vostro primo esempio della classe Anoymous si chiamerà TestClass$1 che non ha alcun metodo doStuff(), viene sostituita solo toString() è per questo che si ottiene NoSuchMethodError errore.

Nel vostro secondo esempio avete già una variabile locale denominata TestClass$1, quindi il nome generato automaticamente scelto dal compilatore sarà un nome diverso, molto probabilmente TestClass$2. Dal momento che si crea un'istanza TestClass$1 che non è una classe anonima, ma una classe esplicitamente definito dall'utente, che verrà creata un'istanza che ha un metodo doStuff() che stampa correttamente "hello2" e che non esclude Object.toString() così la stampa il valore restituito dal suo processo toString() stamperà il default valore specificato in java.lang.Ojbect (che è il nome della classe aggiunto con un segno @ seguito dal codice hash predefinito in formato esadecimale).

Conclusione: Anche se questo è un esempio interessante, non si dovrebbe mai usare il segno $ nei nomi di classe e nei nomi degli identificatori.

Answer 3

ho modificato il codice per rimuovere il "$" dai nomi di classe e rinominato TestClass $ 1 a t e cambiato il println un po 'come segue:

public class TestClass{ 

    public static void main(String...args){ 
     Object t = new Object(){ 
      public String toString() { 
       return "t.toString()"; 
      } 
     }; 
     TestClass1 tc1 = new TestClass1(); 
     System.out.println(t.toString()); 
     tc1.doStuff(); 
    } 
} 

class TestClass1{ 
    public void doStuff(){ 
     System.out.println("TestClass1.doStuff()"); 
    } 
} 

uscita è ora:

t.toString() 
TestClass1.doStuff() 

È questo che ti aspetti?