Sì, come semplice prova va bene. Usare la lib/ext però, in generale, ha dei limiti. Innanzitutto è "globale" per tutte le applicazioni che sono avviate con quello specifico JRE e se due applicazioni avessero bisogno di versioni differenti della stessa libreria, queste non puoi metterle entrambe nella lib/ext. Tra l'altro non c'è nemmeno un ordine di ricerca "garantito", quindi non sapresti a priori quale versione della libreria viene pescata per prima.
Inoltre le classi in jar in lib/ext vengono caricate con un classloader speciale che non "sa" nulla dello user classpath e quindi non va bene per tutte le librerie.
Pertanto, salvo casi particolari, la lib/ext non è poi così utile.
I jar tecnicamente sono degli zip, quindi è tecnicamente possibile fondere insieme il contenuto di più jar a patto che non ci siano doppioni di classi/risorse. C'è il problema del "manifest" che in ogni jar è in un path fisso e ben preciso. Fare un "merge" di più manifest potrebbe non essere così semplice.
Inoltre il fornitore di una libreria potrebbe indicare nella licenza d'uso la richiesta/obbligo di non incorporare il suo jar in un altro.
Quindi in generale, anche questa opzione sarebbe da evitare.
E questo va bene finché sei nel IDE.
Se vuoi avviare la tua applicazione con:
java -jar myapp.jar
allora c'è un solo modo pulito per far sì che myapp.jar referenzi altre librerie, ovvero elencarle nell'attributo Class-Path nel manifest del tuo jar.
Quindi in sostanza avere nel MANIFEST.MF del tuo jar qualcosa tipo:
Class-Path: lib/nome1.jar lib/nome2.jar
Questo lo puoi fare a mano con il tool "jar" oppure con i tool di build es. Apache Ant.
Chiaramente poi ovunque ci sia il myapp.jar ci deve essere una cartella "lib" con dentro le librerie. Insomma la relazione tra i jar deve restare "relativa" in quel senso.


Rispondi quotando