[java]URLClassLoader non trova la classe..

[santaclause83]

allora il mio processo si trova nella cartella sottostante la classe da caricare dinamicamente

mi calcolo l'absolute path,lo inserisco nell'URLclassloader e ci chiamo il metodo loadClass col nome della classe senza l'estensione .class

se la classe risiede nella stessa cartella del processo che la eve reperire e caricare,funziona tutto,altrimenti nada..

questo è il pezzo di codice che cerca e carica la classe:

File percorso = new File(path);

URL[] url = {percorso.toURL()};
ClassLoader cl = new URLClassLoader(url);
Class c = cl.loadClass(eseguibile);

...poi crea l'istanza,mette i parametri e la esegue,ma il progamma
si ferma qua perchè non la trova

[andbin]

Originariamente inviato da santaclause83

File percorso = new File(path);

URL[] url = {percorso.toURL()};

È meglio fare percorso.toURI().toURL().
Lo dice anche la documentazione.

[santaclause83]

fatto,non funziona comunque..che sia un problema di permessi di accesso?

[andbin]

Originariamente inviato da santaclause83

fatto,non funziona comunque..che sia un problema di permessi di accesso?

La precisazione che ho fatto non era quella che risolve il problema.

Domanda: la classe che vuoi caricare è in un package?

[PGI-Bis]

Originariamente inviato da santaclause83

se la classe risiede nella stessa cartella del processo che la eve reperire e caricare,funziona tutto,altrimenti nada..

indagherei in questa direzione. Sappiamo che se lo URLClassLoader non trova la classe desiderata nei percorsi specificati allora si affida ai percorsi del suo genitore.

Se il percorso affidato allo URLClassLoader fosse "errato", il fatto che la classe venga trovata solo se presente nella stessa cartella del processo si spiegherebbe in ragione di ciò che la directory di lavoro è inclusa nel classpath del caricatore di classi standard che è anche il genitore predefinito di un URLClassLoader.

In pratica anche nel caso in cui funziona lo URLClassLoader fa cilecca (cilecca è un tecnicismo ).

Controlla i percorsi che affidi allo URLClassLoader. Va segnalato che se il percorso termina con una barra "/" allora lo URLClassLoader lo interpreta come directory radice del package delle classi caricande. Se il percoso non termina con una barra allora esso è interpretato come il percorso di un singolo file jar (che contiene le classi e le risorse esaminate).

[santaclause83]

si cmque la classe che sto cercando di caricare è in un package,dove risiede anche il processo che la deve caricare..

il nome del package lo devo specificare nell'URLClassLoader?

File percorso = new File(path+<nomepackage>);
try {
URL[] url = {percorso.toURI().toURL()};
ClassLoader cl = new URLClassLoader(url);
Class c = cl.loadClass(eseguibile);

[^TiGeRShArK^]

spè...
se il file da caricare è nel tuo stesso classpath allora che bisogno hai di ridefinirti un altro classloader?
non puoi usare il classloader di default?

[PGI-Bis]

I percorsi dell'URLClassLoader sono o directory o file jar. Se il nome del percorso termina con una barra / allora per URLClassLoader quella è una cartella. Se non termina con / allora è un jar.

Non devi specificare il nome della classe per l'url classloader. Le trova da solo. Se la classe è fornita all'interno di un file jar allora devi passare allo URLClassLoader il percorso di quel file jar. Se la classe è "sfusa" allora devi passare allo URLClassLoader il percorso della directory "radice" del package a cui appartiene la classe. Se la classe si chiama "it.santa.Bingo" la radice del package di questa classe sarà la cartella che contiene la directory "it" (che contiene la directory santa che contiene il file Bingo.class). Supponendo che questa cartella sia "c:\classi" l'url da dare in pasto allo URLClassLoader sarà:

file:///c:/classi/

Il nome termina con una "/" quindi lo URLClassLoader interpreterà quel percorso come radice di uno o più package.

Se la classe si trova in un jar, ipotizziamo "c:\classi\Bingo.jar" allora rifilerai allo URLClassLoader il percorso:

file:///c:/classi/Bingo.jar

[santaclause83]

hai ragione è che prima voglio vedere se la classe riesce a caricarsi nella situazione più banale,poi in realtà dovrei esser capace di caricarla da un altro path,quindi per ora voglio solo vedere se riesce a caricarla..

nel caso voglia caricarla da un altro path..

mettiamo caso risieda in "home/nicholas/workspace/prove"

devo mettere lo slash in fondo se non è un jar,e prima di home però ci vuole lo slash?

[^TiGeRShArK^]

con lo slash iniziale viene considerato un path assoluto, senza lo slash un path relativo.
Quindi nel tuo caso direi che lo slash iniziale va se home si trova all'interno della directory root.

[PGI-Bis]

Originariamente inviato da ^TiGeRShArK^

spè...
se il file da caricare è nel tuo stesso classpath allora che bisogno hai di ridefinirti un altro classloader?
non puoi usare il classloader di default?

Caricando una classe con un diverso ClassLoader tale classe risulterà diversa dalle omonime agli occhi della JVM. Questa diversità consente la c.d. sostituzione dinamica delle definizioni che fonda a sua volta la categoria dei servizi hot-swap (nella piattaforma Java).

Detto altrimenti, caricando una classe "visibile" (ma non già caricata) al ClassLoader predefinito tramite un ClassLoader diverso posso infilare nella JVM una classe sostituibile.

PS: ovviamente se di questa faccenda della sostituibilità ad uno importa più o meno niente allora l'uso del ClassLoader predefinito appare effettivamente più logico se il percorso è già nel classpath

[PGI-Bis]

Tagliamo la testa al toro con un caso pienamente definito.

Supponiamo di avere la classe watanga.Konga in due posizioni diverse sul filesystem.

1. z:\progetti\test\watanga\Konga.class
2. z:\archivi\jar\Konga.jar

Nel caso in cui io voglia caricare la classe watanga.Konga a partire dal file class che si trova in (1), lo URL da passare al ClassLoader è:

file:///z:/progetti/test/

Nel caso in cui io voglia caricare la classe watanga.Konga a partire dal file class che si trova nel jar in (2), lo URL da passare al ClassLoader è:

file:///z:/archivi/jar/Konga.jar

In entrambi i casi parliamo ovviamente di un percorso completo. Nel primo questo percorso è quello della cartella radice del package della classe watanga.Konga, nel secondo il percorso è il percorso completo del file jar che contiene la classe watanga.Konga.