Classi JDK di riserva e ClassLoader "null"?

Question

Salve ragazzi: Sto cercando di eseguire il debug di un errore di classe molto strano guardando i ClassLoader s per alcuni componenti creati dinamicamente. ClassLoader s sono qualcosa con cui non ho mai giocato molto - e sono sorpreso che le classi JDK standard hanno null istanze del caricatore di classe.

Qualcuno può spiegare l'uscita di questo metodo semplice principale in termini di classi di cui caricatori Sto tentando di stampare, e anche più in generale -

1. il modo ClassLoader s lavoro sulla JVM e
2. come possiamo eseguire il debug delle classi mancanti usando ClassLoader s.

public class MyClass { 

    /** 
    * @param args 
    */ 
    public static void main(String[] args) { 

     System.out.println(relfect.MyClass.class.getClassLoader()); 
     System.out.println(String.class.getClassLoader()); 
     System.out.println(ArrayList.class.getClassLoader()); 
     System.out.println(JButton.class.getClassLoader()); 
     System.out.println(System.class.getClassLoader()); 

     Boolean b = new Boolean(true); 
     System.out.println(b.getClass().getClassLoader()); 

    } 

} 

uscita

sun.misc.Launcher$AppClassLoader@1f7182c1 
null 
null 
null 
null 
null 

Answer 1

Javadoc per getClassLoader() dice

Restituisce il caricatore di classe per la classe. Alcune implementazioni possono utilizzare null per rappresentare il caricatore di classe bootstrap. Questo metodo restituirà null in tali implementazioni se questa classe è stata caricata dal loader della classe bootstrap.

Quindi, questo almeno spiega perché si ottiene quel risultato. Ma non spiega perché gli implementatori hanno deciso di farlo in quel modo.

MODIFICA: Dopo aver provato ad aggiungere le mie proprie classi al percorso di boot, esse vengono visualizzate anche come caricatore di classi null.

Answer 2

Il classloader delle classi bootstrap è nullo, non è una classe java.

Non confondere le classi trovate del classpath e quelle caricate dal bootstrap loader. Quest'ultimo è responsabile delle classi JDK principali che si trovano di solito in rt.jar. È un classloader nativo, quindi nessun riferimento verso.

Le classi sul classpath vengono caricate dal classloader di sistema e la classe di essa può essere specificata tramite la proprietà.

Inoltre, il classloader null è considerato un problema di sicurezza e ci sono controlli basati sulla classe del chiamante che ha un classloader nullo.

Answer 3

Ecco come funziona. Ogni volta che JVM tenta di caricare qualsiasi classe, controlla le condizioni sotto riportate.

Se Class viene caricato da Bootstrap ClassPath i.e; jdk \ jre \ lib \ rt.jar, verrà chiamato ClassLoader BootStrap.

Se Class viene caricato da Extension Classpath i.e; jdk \ jre \ lib \ ext * .jar, verrà chiamato Extension ClassLoader.

Se la classe viene caricata dall'applicazione ClassPath i.e; come specificato in Variabile d'ambiente, viene chiamato ClassLoader dell'applicazione.

Poiché Bootstrap ClassLoader non è implementato in java, è implementato in c o C++, quindi non esiste alcun riferimento per questo motivo è che restituisce null. Ma l'estensione e il caricatore della classe Application sono scritti in java, quindi otterrai il riferimento come sun.misc.Launcher$ExtClassLoader@someHexValue e sun.misc.Launcher$AppClassLoader@someHexValue.

Quindi, se si fa qualcosa di simile a questo System.out.println (String.class.getClassLoader()) si otterrà null poiché questa classe è stata chiamata da BootStrap ClassLoader, D'altra parte se si fa la stessa cosa per una classe in percorso Ext o App Class otterrai $ ExtClassLoader @ someHexValue e sun.misc.Launcher$AppClassLoader@someHexValue rispettivamente.