Pericoli dell'utilizzo di reflection per aggiungere file a classpath in fase di esecuzione

Question

Recentemente ho cercato modi per caricare in modo dinamico i file jar nella mia applicazione in fase di esecuzione.

Sono venuto lungo una certa soluzione più volte, che è fondamentalmente un "hack" che ottiene il programma di caricamento classe di sistema e utilizza la reflection per accedere al metodo addurl rotected otherwisep al fine di aggiungere file aggiuntivi al classpath originale in fase di esecuzione. Questa soluzione funziona molto bene ed evita i problemi che si verificano durante la scrittura e l'utilizzo di un caricatore di classi personalizzato selfmade.

Sembra qualcosa di simile a questo:

URLClassLoader sysloader = (URLClassLoader) ClassLoader.getSystemClassLoader(); 
Class sysclass = URLClassLoader.class; 

try { 
     Method method = sysclass.getDeclaredMethod("addURL", parameters); 
     method.setAccessible(true); 
     method.invoke(sysloader, new Object[] { u }); 
} catch (Throwable t) { 
     t.printStackTrace(); 
     throw new IOException("Error, could not add URL to system classloader"); 
} 

La mia domanda è la seguente: Presumo che ci sia una buona ragione per fare il metodo addurl protetta, in primo luogo, ci deve essere un qualche tipo di insidie ​​o pericoli quando si aggiungono file al classpath in modo dinamico.

Oltre a presupporre che il programma di caricamento di classe del sistema sia sempre un URLClassLoader, che "dovrebbe sempre essere il caso" (TM), che tipo di problema posso incontrare quando utilizzo questo "hack"?

Grazie

Answer 1

Il pericolo principale è il vostro affidamento su una verifica fase di esecuzione dell'esistenza metodi.

Se la firma del metodo cambia in futuro, non la conoscerai fino al runtime. Questo potrebbe anche lasciare una brutta situazione se non viene fornito alcun metodo alternativo.

Inoltre, come enorme afferma già, i progettisti scelgono di rendere il metodo protected per un motivo (a parte poi la mancanza di accortezza)