Migrazione ai moduli

Pochi progetti adottano i moduli fin dall'inizio. JPMS è stato progettato per una migrazione graduale, consentendo la coesistenza di classpath e module path.

Gli elementi fondamentali sono i moduli automatici e il modulo senza nome.

Tutto ciò che viene caricato dal classpath vive nell'unico modulo senza nome. Esso legge ogni altro modulo ed esporta tutti i suoi package.

Questo è il ponte che mantiene funzionante il codice legacy sul classpath.

Una regola fondamentale: un modulo denominato esplicito non può dipendere dal modulo senza nome. Non si può scrivere requires per il codice sul classpath.

Quindi migri dal basso verso l'alto: prima converta la rappresentazione delle dipendenze.

Inserisca un JAR semplice (non modulare) nel module path e diventerà un modulo automatico. Gli verrà assegnato un nome derivato automaticamente, leggerà tutti gli altri moduli ed esporterà tutti i suoi package.

In questo modo i moduli denominati possono dichiarare requires per un JAR che non contiene ancora module-info.

Il nome di un modulo automatico viene derivato secondo questo ordine di preferenza:

• La voce Automatic-Module-Name nel manifest del JAR, se presente
• Altrimenti, dal nome del file JAR (versione rimossa, trattini convertiti in punti)

Gli autori di librerie dovrebbero aggiungere Automatic-Module-Name al manifest prima di modularizzare completamente. In questo modo garantiscono un nome di modulo stabile, così le clausole requires dei moduli dipendenti rimangono valide quando arriverà il vero module-info.

L'approccio consigliato per la propria applicazione è il seguente:

• Mantenga le dipendenze come moduli automatici nel module path
• Aggiunga prima un module-info.java al modulo principale
• Dichiari requires per i nomi di quei moduli automatici

Supponga che guava-32.jar si trovi nel module path come modulo automatico com.google.common. Il modulo dell'applicazione può già dichiarare di richiederlo.

Il sistema dei moduli vieta che due moduli contengano lo stesso package. Le vecchie librerie che suddividono un package tra più JAR causano errori.

Risolva unendo i JAR, usando --patch-module oppure eseguendo l'upgrade a versioni che eliminano la divisione.

I framework che usano la reflection profonda possono non funzionare con InaccessibleObjectException dopo la modularizzazione. Aggiunga direttive opens oppure, come ponte temporaneo, il flag di avvio --add-opens.

Lo strumento jdeps analizza i JAR, segnala le dipendenze, rileva l'uso di API interne del JDK e può persino generare un module-info.java candidato con jdeps --generate-module-info.

Lo esegua per primo per pianificare la migrazione.

Ricordi come un JAR semplice acquisisce un'identità di modulo.

Ha appreso le tecniche di migrazione:

• Il codice sul classpath vive nel modulo senza nome; i moduli denominati non possono dichiarare requires per esso
• I JAR semplici nel module path diventano moduli automatici
• Imposti Automatic-Module-Name per ottenere nomi stabili
• Presti attenzione ai package divisi e all'accesso tramite reflection; usi jdeps per pianificare

Il corso su JPMS è completo.