Storia. Prima di Java 9, la riflessione poteva eludere arbitrariamente i modificatori di accesso tramite setAccessible(true), rompendo l'incapsulamento a piacimento. L'introduzione del Java Platform Module System (JPMS) ha stabilito un'incapsulazione forte per impostazione predefinita, in cui i moduli devono esplicitamente concedere il permesso per l'accesso riflessivo profondo ai loro pacchetti interni.
Problema. Quando il codice in un modulo tenta di utilizzare MethodHandles o la riflessione core per accedere a un campo non pubblico nel pacchetto di un altro modulo, la JVM esegue un rigoroso controllo di accessibilità. Questa verifica assicura che il pacchetto di destinazione sia stato esplicitamente aperto al modulo chiamante. Senza questo permesso, la JVM solleva un'InaccessibleObjectException (o un'IllegalAccessException per la riflessione legacy), indipendentemente dal fatto che sia installato un SecurityManager o che il campo venga accesso tramite VarHandle.
Soluzione. Il modulo deve dichiarare opens package.name [to specific.module]; nel suo module-info.java, oppure l'applicazione deve essere avviata con il flag --add-opens source.module/package.name=target.module. Questa direttiva modifica dinamicamente il grafo di accessibilità interna del modulo, aggiungendo il modulo di destinazione al set di moduli autorizzati a eseguire riflessione profonda sui membri privati di quel pacchetto.
// Modulo: app.core (module-info.java) module app.core { // Il pacchetto com.app.internal non è aperto exports com.app.api; } // Modulo: framework.inject public class Injector { public void inject(Object target) throws Throwable { MethodHandles.Lookup lookup = MethodHandles.privateLookupIn( target.getClass(), MethodHandles.lookup() ); // Solleva InaccessibleObjectException senza --add-opens VarHandle handle = lookup.findVarHandle( target.getClass(), "secretField", String.class ); handle.set(target, "injected"); } }
Un team di sviluppo ha migrato la propria applicazione monolitica basata su Spring al Java Module System, suddividendo il codice in un modulo di logica aziendale principale (app.core) e un modulo di framework di iniezione delle dipendenze separato (framework.inject). Immediatamente dopo il deploy, l'applicazione è andata in crash durante l'inizializzazione del bean con un'InaccessibleObjectException quando il framework ha tentato di iniettare valori di configurazione in campi privati all'interno del pacchetto interno com.app.internal di app.core.
Tre potenziali soluzioni architettoniche sono state valutate. Il primo approccio prevedeva il riposizionamento di tutte le classi iniettabili in pacchetti esportati all'interno di app.core. Sebbene questo risolvesse la violazione di accesso immediata, violerebbe fondamentalmente i principi di incapsulamento esponendo i dettagli di implementazione interni a tutti gli altri moduli, aumentando così il carico di manutenzione e ampliando la superficie di attacco per futuri audit di sicurezza. La seconda soluzione proponeva di utilizzare l'argomento JVM --add-exports per esporre i pacchetti interni al modulo del framework. Tuttavia, sebbene --add-exports conceda visibilità a livello di compilazione e runtime ai tipi pubblici, non consente esplicitamente la riflessione profonda sui membri privati, rendendolo insufficiente per i meccanismi di iniezione dei campi di Spring che richiedono di modificare lo stato privato. La terza opzione ha utilizzato l'argomento da riga di comando mirato --add-opens app.core/com.app.internal=framework.inject. Questo approccio ha mantenuto un'incapsulazione rigorosa a livello di codice sorgente per tutti gli altri moduli, pur concedendo esplicitamente solo al framework di iniezione i privilegi necessari per eseguire riflessione profonda sul pacchetto interno specifico.
Il team ha infine selezionato la terza opzione, documentando le direzioni --add-opens richieste nei propri script di deployment e configurazioni Docker. Questa soluzione ha preservato l'integrità del sistema di modulo durante lo sviluppo, consentendo al framework di funzionare correttamente, risultando in una migrazione di successo con confini di accesso esplicitamente controllati.
Perché setAccessible(true) non funziona su un campo privato all'interno di un pacchetto esportato quando viene accesso da un modulo diverso, nonostante l'assenza di un SecurityManager?
I candidati spesso confondono l'esportazione del pacchetto con l'apertura. La direttiva exports rende solo i tipi pubblici e i membri accessibili per la compilazione e l'invocazione standard; non concede il ReflectPermission necessario per sopprimere i controlli di accesso del linguaggio Java. L'incapsulazione forte del JPMS opera indipendentemente dal SecurityManager, applicata direttamente dai meccanismi di controllo accessi della JVM. Per abilitare setAccessible(true) su membri non pubblici, il pacchetto deve essere esplicitamente dichiarato come open, oppure l'intero modulo deve essere dichiarato come un open module.
Come influenza il meccanismo di cattura di MethodHandles.Lookup l'accessibilità tra moduli, e perché l'invocazione di MethodHandles.lookup().in(targetClass) potrebbe degradare le capacità di lookup?
Un oggetto Lookup incapsula i privilegi di accesso del contesto del modulo e del pacchetto del suo creatore. Quando viene invocato Lookup.in(targetClass), la JVM rivaluta i privilegi del lookup in base al modulo della classe di destinazione. Se la classe di destinazione si trova in un modulo diverso che non ha aperto il suo pacchetto al modulo del lookup, il lookup viene "degradato" a modalità PUBLIC, privandolo dei diritti di accesso PRIVATE e MODULE. Per mantenere pieni diritti di accesso tra moduli, il modulo di destinazione deve esplicitamente aprire il pacchetto al modulo del lookup, oppure il codice deve utilizzare privateLookupIn, il che richiede che la classe di destinazione sia all'interno dello stesso modulo o accessibile tramite il grafo dei moduli.
Qual è la distinzione fondamentale tra --add-exports e --add-opens a livello di JVM, e perché il primo causa IllegalAccessException durante l'iniezione delle dipendenze anche quando la compilazione ha successo?
L'argomento --add-exports aggiunge un pacchetto alla lista dei pacchetti esportati del modulo, consentendo al modulo di destinazione di accedere a tipi pubblici sia a tempo di compilazione che a runtime. Tuttavia, questa direttiva non modifica il set "open" del modulo, che controlla la riflessione profonda. La Java Language Specification separa rigorosamente la leggibilità (esporta) dalla riflettibilità (aperture). I framework di iniezione delle dipendenze richiedono quest'ultima per manipolare campi privati tramite Reflection o VarHandle. Di conseguenza, mentre --add-exports soddisfa il compilatore e consente l'invocazione dei metodi, i tentativi di runtime di modificare lo stato privato falliranno ancora. Solo --add-opens aggiunge il pacchetto al set di pacchetti accessibili per la riflessione profonda, consentendo così al framework di modificare i valori dei campi privati.