Ho creato un barattolo sigillato, ma non vedo differenze rispetto all'uso di uno non sigillato.
Puoi verificare che un vaso sia sigillato definendo una classe che esiste in un pacchetto usato nel file jar. Se il barattolo è sigillato, tutti i pacchi sono normalmente sigillati, altrimenti è possibile sigillarli in base al pacchetto. La classe che crei dovrebbe quindi provare ad accedere ai membri protetti o predefiniti di una classe in quel pacchetto.
Ad esempio, se il jar ha una classe com.example.Widget in cui il pacchetto com.example è sealed e Widget ha membri protetti / predefiniti, crea una classe com.example.Test che tenta di accedere a tali membri. Questo dovrebbe fallire.
Il motivo della chiusura deriva da una descrizione di come testarlo: vuoi che il tuo codice sia autonomo e gli utenti del contenitore dovrebbero solo utilizzare i membri pubblici. Non è necessario che i pacchetti siano univoci tra i jar (e le cartelle bin nel tuo IDE) usati da un programma. Sei in grado di definire una classe nello stesso pacchetto di un contenitore e accedere a membri protetti / predefiniti che potrebbero causare problemi. Spesso, la visibilità predefinita viene utilizzata come parola chiave friend di un analogo a C ++ consentendo ad altre classi nello stesso pacchetto di eseguire azioni che sono sicure solo perché gli stessi programmatori lavorano su entrambe le classi e comprendono i loro interni. Forse un metodo di visibilità predefinito rinuncia ad alcuni limiti controllando il nome delle prestazioni, con la consapevolezza che il codice cliente non accederà mai a esso. Ad esempio, la classe String in Java ha alcuni di questi tipi di metodi poiché la gestione delle stringhe deve essere velocissima perché una grande quantità di codice si basa su di essa. BigDecimal è costruito su BigInteger e utilizza l'accesso predefinito per ottimizzare alcune operazioni che altri utenti della classe non dovrebbero utilizzare.
TL; DR : le classi nello stesso pacchetto potrebbero accedere a membri non pubblici di ciascuna altro per prestazioni o semplicità. Questo accesso potrebbe non controllare invarianti e precondizioni. Si possono mettere le classi nello stesso pacchetto in più posizioni nel classpath. Sigillare un pacchetto o un barattolo impedisce al codice client di accedere a questi metodi, perché altrimenti potrebbe causare problemi.
Questo non causerà alcun problema agli utenti del barattolo. Il meccanismo di caricamento classi che accede alle risorse (ad esempio i file di classe) nei jar supporta completamente i pacchetti ei pacchetti sigillati.
Lettura correlata: Tenuta di pacchetti all'interno di un file JAR
Per rispondere alla tua seconda domanda, sigilliamo i nostri Jars come misura di sicurezza, in quanto ciò impedisce una forma di iniezione del codice in cui ulteriori classi vengono aggiunte alla nostra base di codice in fase di esecuzione.
Abbiamo una certa quantità di riflessione nel nostro codice in cui gli oggetti vengono creati in base all'input dell'utente. Il codice che crea questi oggetti consentirà l'istanziazione di classi da nomi di pacchetti fissi.
Sigillando i barattoli che contengono le classi che vogliamo che gli utenti siano in grado di creare, l'utente non è in alcun modo in grado di creare nuove classi potenzialmente pericolose e il nostro software può istanziarle in fase di esecuzione. A meno che la classe non sia nel pacchetto corretto, il nostro codice non la caricherà e sigillare i jar vuol dire che solo le classi a cui gli utenti devono accedere sono accessibili.
Se i nostri jar non fossero sigillati, l'utente potrebbe potenzialmente aggiungere nuove classi che potrebbero essere istanziate. Questo sarebbe un rischio per la sicurezza.
TL; DR: Sigillando i tuoi jar, puoi prevenire un tipo di iniezione di codice dannoso.