Qual è la differenza tra Class.getResource () e ClassLoader.getResource ()?

Mi chiedo quale sia la differenza tra Class.getResource()e ClassLoader.getResource()?

modifica: in particolare voglio sapere se è coinvolta la memorizzazione nella cache a livello di file / directory. Come in "gli elenchi di directory sono memorizzati nella cache nella versione Class?"

AFAIK quanto segue dovrebbe essenzialmente fare lo stesso, ma non lo sono:

getClass().getResource() 
getClass().getClassLoader().getResource()

L'ho scoperto mentre cercavo un po 'di codice per la generazione di report che crea un nuovo file WEB-INF/classes/da un file esistente in quella directory. Quando ho usato il metodo di Class, sono riuscito a trovare i file presenti al momento della distribuzione utilizzando getClass().getResource(), ma quando ho cercato di recuperare il file appena creato, ho ricevuto un oggetto null. La navigazione nella directory mostra chiaramente che il nuovo file è lì. I nomi dei file sono stati anteposti con una barra come in "/myFile.txt".

La ClassLoaderversione di getResource()d'altra parte ha trovato il file generato. Da questa esperienza sembra che ci sia una specie di memorizzazione nella cache dell'elenco delle directory in corso. Ho ragione, e se sì, dove è documentato?

Dai documenti API in poiClass.getResource()

Trova una risorsa con un determinato nome. Le regole per la ricerca di risorse associate a una determinata classe sono implementate dal caricatore di classi di definizione della classe. Questo metodo delega al programma di caricamento classi di questo oggetto. Se questo oggetto è stato caricato dal programma di caricamento classi bootstrap, il metodo delega a ClassLoader.getSystemResource (java.lang.String).

Per me, questo dice "Class.getResource sta davvero chiamando getResource ()" del proprio classloader. Sarebbe lo stesso che fare getClass().getClassLoader().getResource(). Ma ovviamente non lo è. Qualcuno potrebbe fornirmi un po 'di illuminazione in questa faccenda?

Per rispondere alla domanda se è in corso la memorizzazione nella cache.

Ho analizzato ulteriormente questo punto eseguendo un'applicazione Java autonoma che ha caricato continuamente un file dal disco utilizzando il metodo getResourceAsStream ClassLoader. Sono stato in grado di modificare il file e le modifiche sono state immediatamente riflesse, ovvero il file è stato ricaricato dal disco senza memorizzazione nella cache.

Tuttavia: sto lavorando a un progetto con diversi moduli maven e progetti Web che hanno dipendenze reciproche. Sto usando IntelliJ come mio IDE per compilare ed eseguire i progetti web.

Ho notato che quanto sopra sembrava non essere più vero, il motivo è che il file che stavo caricando è ora cotto in un barattolo e distribuito nel progetto web dipendente. L'ho notato solo dopo aver provato a cambiare il file nella mia cartella di destinazione, senza risultati. Ciò ha fatto sembrare che ci fosse la cache in corso.

Class.getResourcepuò assumere un nome di risorsa "relativo", che viene trattato rispetto al pacchetto della classe. In alternativa è possibile specificare un nome di risorsa "assoluto" utilizzando una barra iniziale. I percorsi delle risorse del classloader sono sempre considerati assoluti.

Quindi i seguenti sono sostanzialmente equivalenti:

foo.bar.Baz.class.getResource("xyz.txt");
foo.bar.Baz.class.getClassLoader().getResource("foo/bar/xyz.txt");

E così sono questi (ma sono diversi da quelli sopra):

foo.bar.Baz.class.getResource("/data/xyz.txt");
foo.bar.Baz.class.getClassLoader().getResource("data/xyz.txt");

La prima chiamata cerca in relazione al .classfile mentre la seconda cerca in relazione alla radice del percorso di classe.

Per eseguire il debug di problemi del genere, stampo l'URL:

System.out.println( getClass().getResource(getClass().getSimpleName() + ".class") );

Ho dovuto cercarlo nelle specifiche:

• Class.getResource (risorsa stringa)

• ClassLoader.getResource (risorsa stringa)

GetResource () della classe - la documentazione indica la differenza:

Questo metodo delega la chiamata al proprio caricatore di classi, dopo aver apportato queste modifiche al nome della risorsa: se il nome della risorsa inizia con "/", rimane invariato; in caso contrario, il nome del pacchetto viene anteposto al nome della risorsa dopo la conversione "." per "/". Se questo oggetto è stato caricato dal caricatore bootstrap, la chiamata viene delegata a ClassLoader.getSystemResource.

Tutte queste risposte qui intorno, così come le risposte a questa domanda , suggeriscono che il caricamento di URL assoluti, come "/foo/bar.properties", ha trattato lo stesso di class.getResourceAsStream(String)e class.getClassLoader().getResourceAsStream(String). Questo NON è il caso, almeno non nella mia configurazione / versione di Tomcat (attualmente 7.0.40).

MyClass.class.getResourceAsStream("/foo/bar.properties"); // works!  
MyClass.class.getClassLoader().getResourceAsStream("/foo/bar.properties"); // does NOT work!

Mi dispiace, non ho assolutamente una spiegazione soddisfacente, ma immagino che Tomcat faccia trucchi sporchi e la sua magia nera con i caricatori di classe e faccia la differenza. Ho sempre usato class.getResourceAsStream(String)in passato e non ho avuto problemi.

PS: l'ho anche pubblicato qui

Class.getResourcesrecupererebbe la risorsa dal classloader che carica l'oggetto. Mentre ClassLoader.getResourcerecupererebbe la risorsa usando il classloader specificato.

Ho provato a leggere da input1.txt che era dentro uno dei miei pacchetti insieme alla classe che stava cercando di leggerlo.

Le seguenti opere:

String fileName = FileTransferClient.class.getResource("input1.txt").getPath();

System.out.println(fileName);

BufferedReader bufferedTextIn = new BufferedReader(new FileReader(fileName));

La parte più importante era chiamare getPath()se si desidera il nome percorso corretto in formato String. NON UTILIZZAREtoString() perché aggiungerà del testo di formattazione aggiuntivo che TOTALMENTE TOTALE il nomefile (puoi provarlo e vedere la stampa).

Ho trascorso 2 ore a eseguire il debug di questo ... :(