'volatile' nella firma del metodo?

Question

Questo è strano. Ho il seguente codice:

class A 
{ 
    protected A clone() throws CloneNotSupportedException 
    { 
     return (A) super.clone();  
    } 
} 

quando de-compilato il suo bytecode tramite 'showmycode.com', mi ha mostrato il seguente codice:

class A 
{ 

    A() 
    { 
    } 

    protected A clone() 
    throws clonenotsupportedexception 
    { 
     return (A)super.clone(); 
    } 

    protected volatile object clone() 
    throws clonenotsupportedexception 
    { 
     return clone(); 
    } 
} 

Che cosa significa per un tipo di metodo di ritorno essere volatili nel secondo metodo "clone"? (Questo codice è stato compilato tramite il compilatore JDK 1.6 predefinito di Eclipse).

Answer 1

La maschera di modifica per campi e metodi è simile ma non esattamente la stessa. Il Decompiler è più probabile con il metodo toString qui

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/reflect/Modifier.java

ma quello che non fa è di gestire tutti i bit

// Bits not (yet) exposed in the public API either because they 
// have different meanings for fields and methods and there is no 
// way to distinguish between the two in this class, or because 
// they are not Java programming language keywords 

ciò che il suo non gestisce è il bit che può significare synthetic e bridge che identificano il codice generato dal compilatore.

Se volatile significa qualcosa qui, potrebbe significare non rimuovere il metodo anche se non fa nulla.

Answer 2

Si tratta di un bug nel decompilatore.

volatile è solo un modificatore valido per un campo.

Vi consiglio di leggere l'articolo this.

Answer 3

Non significa niente. È un bug nel decompilatore. Fine della storia.

(Il bug è probabilmente correlato al fatto che alcuni bit di flag utilizzati nel formato di file di classe sono "sovraccaricati", ovvero cose diverse nel contesto di una classe, un campo o un metodo.Vedo anche vagamente che ci sono stati alcuni "nuovi usi" nelle recenti revisioni di specifiche JVM.)

Answer 4

Questa risposta è già stata illustrata nella domanda Why make a method volatile in java? Ma ecco alcune ulteriori informazioni.

Quando si sovraccaricano metodi (probabilmente solo metodi generici nella superclasse), il metodo è contrassegnato come "bridge method". Da java.lang.reflect.Modifier:

static final int BRIDGE = 0x00000040; 

Purtroppo, questo è lo stesso bit che viene utilizzato per contrassegnare i campi come volatile:

public static final int VOLATILE   = 0x00000040; 

Se si stampano i modificatori su quel metodo si vedrà qualcosa di simile:

public volatile 

Questa è una limitazione nel metodo Modifiers.toString(int) che non sa se si tratta di un campo o di un metodo.

public static String toString(int mod) { 
    StringBuffer sb = new StringBuffer(); 
    ... 
    if ((mod & VOLATILE) != 0) sb.append("volatile "); 
    // no mention of BRIDGE here 
    ... 
    return sb.toString().substring(0, len-1); 
}