Il meccanismo che permette di scaricare ed eseguire dinamicamente classi provenienti anche da server remoti dipende dal cosiddetto class loader, di cui si parla in questo <a href="http://java.sun.com/developer/technicalArticles/Networking/classloaders/" target="_blank">articolo</a> sul sito Sun. Ovviamente il <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ClassLoader.html" target="_blank">ClassLoader</a> è una classe astratta Java, che permette di estendere le modalità di caricamento delle classi da parte della JVM.

Dei diversi class loader, uno ad esempio serve a caricare le classi cosiddette trusted, che non richiedono validazione in quanto appunto ritenute affidabili oltre che necessarie per l'avvio del programma. C'è poi un loader per le API standard del linguaggio, e uno di sistema che va a leggere nel classpath.

Per curiosità si può usare uno dei tanti switch del comando java, -verbose, che serve proprio a sapere quali classi vengono caricate nell'esecuzione di un programma, anche se solitamente l'output è per l'appunto molto <em>verboso</em>, e quindi praticamente illeggibile per eccesso di informazione. La sinassi del comando in questo semplice esempio: <em>java -verbose:class MyClass</em>

Lo sviluppo di un class loader personalizzato è semplificata delle nuove classi introdotte da Sun, come ad esempio <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/security/SecureClassLoader.html" target="_blank">java.security.SecureClassLoader</a>, oppure  <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLClassLoader.html" target="_blank">java.net.URLClassLoader</a>, classe che estende ClassLoader aggiungendo il supporto per la ricerca di un PATH di rete, in partica un URL che fa riferimento a directory e file JAR.
Con questo meccanismo è possibile costruire un'applicazione che carica classi e risorse da server remoti, basta definire gli URL in cui ricercare le classi: un URL che termina con il carattere '/' farà riferimento a una directory, altrimenti si darà per scontato il riferimento a un file JAR.

La classe ClassLoader ha un metodo loadClass(String name) che serve a caricare la classe passata come parametro, e di cui sarà chiamato il costruttore dell'istanza, anche se Sun raccomanda di effettuare l'override del metodo findClass(). L'esempio di loader fornito da Sun è molto breve e semplice: il classico Hello there via URL, in pratica viene eseguita una classe scaricata su un server. Se si crea un file jar le modalità di accesso sono più o meno le stesse. Il codice è reperible all'indirizzo <a href="http://www.javacourses.com/classes/test.jar" target="_blank">http://www.javacourses.com/classes/test.jar</a>.
Interessante l'esempio che usa l'API reflection per rappresentare le cratteristiche di un oggetto di cui non si conoscono i metodi.

In tempi di paranoia è fin troppo ovvio che l'esecuzione di codice proveniente da chissà dove sul proprio sistema possa comportare dei rischi: l'esempio proposto, abbastanza surreale, comporta la cancellazione di un file importante, resa possibile dal fatto che i meccanismi di sicurezza distinguono tra codice <em>malicious</em>, che eseguono, e <em>invalid</em>, che invece viene bloccato dai meccanismi di sicurezza della VM.

Una possibile difesa da questi attacchi è data dall'uso di un security manager unito a un file di testo contenente una security policy: se si tentano operazioni illecite dal punto di vista della sicurezza viene sollevata un'eccezione.
Insomma, grazie ai class loader si possono eseguire dinamicamente varie classi provenienti da filesystem locali o remoti, facendo attenzione ai rischi e proteggendosi con meccanismi che rallentano un poco la poduttività a beneficio della sicurezza.