Java-platformmodulesysteem - Java Platform Module System
Het Java Platform Module System specificeert een distributie-indeling voor verzamelingen Java- code en bijbehorende bronnen. Het specificeert ook een repository voor het opslaan van deze collecties, of modules , en identificeert hoe ze kunnen worden ontdekt, geladen en gecontroleerd op integriteit. Het bevat functies zoals naamruimten met als doel enkele van de tekortkomingen in het bestaande JAR- formaat op te lossen , met name de JAR Hell , wat kan leiden tot problemen zoals klassenpad en problemen met het laden van klassen.
Het Java-modulesysteem werd aanvankelijk ontwikkeld onder het Java Community-proces als JSR 277 en zou samen met Java 7 worden uitgebracht.
JSR 277 werd later in de wacht gezet en Project Jigsaw werd gemaakt om de JDK te modulariseren. Deze JSR is vervangen door JSR 376 (Java Platform Module System).
Project Jigsaw was oorspronkelijk bedoeld voor Java 7 (2011) maar werd uitgesteld tot Java 8 (2014) als onderdeel van Plan B, en opnieuw uitgesteld tot een Java 9- release in 2017. Java 9 inclusief het Java Module System werd uitgebracht op 21 september, 2017.
architectuur
Het Java-modulesysteem dat in Java 9 is geïmplementeerd, omvat de volgende JEP's en JSR (Java Specification Request) :
- JEP 200: De modulaire JDK: definieer een modulaire structuur voor de JDK
- JEP 201: Modulaire broncode: reorganiseer de JDK-broncode in modules, verbeter het bouwsysteem om modules te compileren en handhaving van modulegrenzen tijdens het bouwen
- JEP 220: Modulaire runtime-images: herstructureer de JDK- en JRE-runtime-images om modules onder te brengen en de prestaties, beveiliging en onderhoudbaarheid te verbeteren
- JEP 261: Modulesysteem: het Java-platformmodulesysteem implementeren
- JEP 282: The Java Linker: maak een tool die een set modules en hun afhankelijkheden kan samenstellen en optimaliseren tot een aangepast runtime-image
- JSR 376: Java-platformmodulesysteem
Daarnaast zijn er verschillende andere JDK 9-functies toegevoegd om de overgang naar het modulesysteem te vergemakkelijken:
- JEP 238: Multi-Release JAR-bestanden: Breid het JAR-bestandsformaat uit zodat meerdere Java-release-specifieke versies van klassebestanden naast elkaar kunnen bestaan in één archief.
- JEP 253: JavaFX UI-besturingselementen en CSS-API's voorbereiden voor modulatie: openbare API's definiëren voor de JavaFX-functionaliteiten die momenteel alleen beschikbaar zijn via interne API's en ontoegankelijk zouden worden vanwege modularisatie.
- JEP 260: de meeste interne API's inkapselen: maak de meeste interne API's van de JDK standaard ontoegankelijk, maar laat een paar kritieke, veelgebruikte interne API's toegankelijk totdat er ondersteunde vervangingen zijn voor alle of de meeste van hun functionaliteit.
- JEP 275: Modulaire Java-toepassingsverpakking: De Java-packer zal evolueren voor JDK 9, waardoor het zich bewust wordt van modules, waardoor het bijvoorbeeld mogelijk wordt om een module en alle modules waarvan het afhankelijk is te verpakken.
Eigenschappen van modules
Modules zijn een nieuwe manier om code te groeperen. In tegenstelling tot Jar-bestanden verklaren modules expliciet van welke modules ze afhankelijk zijn en welke pakketten ze exporteren. Expliciete afhankelijkheidsverklaringen verbeteren de integriteit van de code, door het gemakkelijker te maken om te redeneren over grote applicaties en de afhankelijkheden tussen softwarecomponenten.
De volgende moduleverklaring verklaart bijvoorbeeld dat de module com.foo.bar afhankelijk is van een andere com.foo.baz- module en exporteert de volgende pakketten: com.foo.bar.alpha en com.foo.bar.beta :
module com.foo.bar {
requires com.foo.baz;
exports com.foo.bar.alpha;
exports com.foo.bar.beta;
}
De openbare leden van de com.foo.bar.alpha- en com.foo.bar.beta- pakketten zullen toegankelijk zijn via afhankelijke modules. Particuliere leden zijn zelfs ontoegankelijk via een middel als reflectie , hoewel of 'illegale toegang' de facto is toegestaan, afhangt van een opdrachtregelinstelling.
In tegenstelling tot het Jar-bestandsformaat, zal de module deze afhankelijkheden beschrijven in een moduledeclaratie die in een bestand met de naam module-info.java in de root van de bronbestandhiërarchie van de module wordt geplaatst. De JDK zal in staat zijn om afhankelijkheden en interacties tussen modules te verifiëren, zowel tijdens compile-time als runtime. De JDK zelf is gemodulariseerd in Java 9 .
Koppelingen met OSGi
Het Java Module Systeem is niet bedoeld om alle functionaliteiten te ondersteunen die het OSGi- platform momenteel ondersteunt (bijvoorbeeld het Life-Cycle-model en de Services Registry). Het Java-modulesysteem ondersteunt echter functies die niet door OSGi worden ondersteund, zoals modulariteit tijdens het compileren en ingebouwde ondersteuning voor native bibliotheken. In 2016 zijn een aantal artikelen gepubliceerd waarin wordt onderzocht hoe het Java Module System en OSGi kunnen samenwerken. Deze zijn te vinden op InfoQ en ook op het OSGi Alliance Blog.
