Migreren naar modules

Weinig projecten voeren vanaf het begin modules in. JPMS is ontworpen voor een geleidelijke migratie, waarbij classpath en modulepad naast elkaar kunnen bestaan.

De belangrijkste onderdelen zijn automatische modules en de naamloze module.

Alles wat vanaf het classpath wordt geladen, leeft in de ene naamloze module. Deze leest elke andere module en exporteert al zijn pakketten.

Dit is de brug die ervoor zorgt dat oudere classpath-code blijft werken.

Een belangrijke regel: een expliciet benoemde module kan niet afhankelijk zijn van de naamloze module. Je kunt geen requires schrijven voor classpath-code.

Daarom migreer je van onder naar boven: zet eerst de representatie van je afhankelijkheden om.

Plaats een gewone, niet-modulaire JAR op het modulepad en deze wordt een automatische module. De module krijgt een automatisch afgeleide naam, leest alle andere modules en exporteert al zijn pakketten.

Zo kunnen benoemde modules een JAR met requires gebruiken terwijl die nog geen module-info heeft.

De naam van een automatische module wordt afgeleid in deze volgorde:

• De vermelding Automatic-Module-Name in het JAR-manifest, als die aanwezig is
• Anders uit de bestandsnaam van de JAR, waarbij de versie wordt verwijderd en koppeltekens in punten worden veranderd

Auteurs van bibliotheken zouden Automatic-Module-Name aan hun manifest moeten toevoegen voordat ze volledig modulair worden. Zo beloven ze een stabiele modulenaam, zodat de requires-clausules van afhankelijke projecten blijven werken wanneer de uiteindelijke echte module-info wordt toegevoegd.

De aanbevolen aanpak voor je eigen toepassing:

• Houd afhankelijkheden als automatische modules op het modulepad
• Voeg eerst een module-info.java toe aan jouw bovenste module
• Declareer requires voor de namen van die automatische modules

Stel dat guava-32.jar als de automatische module com.google.common op het modulepad staat. Je toepassingsmodule kan er al een requires voor hebben.

Het modulesysteem verbiedt dat twee modules hetzelfde pakket bevatten. Oudere bibliotheken die een pakket over meerdere JAR's verdelen, veroorzaken fouten.

Los dit op door de JAR's samen te voegen, --patch-module te gebruiken of te upgraden naar versies waarin het probleem met het gesplitste pakket is opgelost.

Raamwerken die diepe reflectie uitvoeren, kunnen na het modulariseren mislukken met InaccessibleObjectException. Voeg richtlijnen opens toe of gebruik tijdelijk de startoptie --add-opens.

Het hulpmiddel jdeps analyseert je JAR's, rapporteert afhankelijkheden, markeert het gebruik van interne JDK-API's en kan zelfs een mogelijke module-info.java genereren met jdeps --generate-module-info.

Voer het eerst uit om je migratie te plannen.

Je hebt migratietechnieken geleerd:

• Classpath-code leeft in de naamloze module; benoemde modules kunnen er geen requires voor hebben
• Gewone JAR's op het modulepad worden automatische modules
• Stel Automatic-Module-Name in voor stabiele namen
• Let op gesplitste pakketten en toegang via reflectie; gebruik jdeps om te plannen

Daarmee is de JPMS-cursus voltooid.