De ServiceLoader faalt in het lokaliseren van providers wanneer de bijbehorende module geen provides ... with-richtlijn verklaart in zijn module-info.java-descriptor. Het Java Platform Module System (JPMS) handhaaft standaard sterke encapsulatie, waardoor de ServiceLoader (gelegen in java.base) geen toegang heeft tot klassen in pakketten die niet zijn geëxporteerd of geopend. De provides-richtlijn fungeert als een contractuele verklaring die de ServiceLoader het privilege verleent om de opgegeven providerklasse te instantiëren, waarmee de normale toegankelijkheidsbeperkingen van het pakket worden omzeild zonder dat het pakket aan alle modules hoeft te worden geëxporteerd.
Context: Een legacy enterprise CRM-systeem werd gemigreerd van Java 8 naar Java 17. Het doel was om de monolithische architectuur te modulariseren in afzonderlijke domeinen: crm-core, crm-email en crm-api. De crm-email-module bevatte een implementatie van de NotificationService-interface die in crm-api is gedefinieerd.
Na de migratie gooide de applicatie een ServiceConfigurationError tijdens de opstart. Dit gebeurde ondanks dat de EmailNotificationService-klasse publiek was en de JAR-bestanden aanwezig waren op het modulepad. De stacktrace gaf aan dat er geen providers voor het servicetype werden gevonden, wat leidde tot een mislukte initialisatie van het notificatiesysteem.
Probleem: Het ontwikkelingsteam ging ervan uit dat de publieke zichtbaarheid van de implementatieklasse voldoende was. Dit weerspiegelde aannames uit het classpath-tijdperk waarbij publieke klassen wereldwijd zichtbaar waren. Echter, JPMS voorkomt dat de ServiceLoader toegang heeft tot klassen in niet-geëxporteerde pakketten van andere modules. De crm-email-module exporteerde het com.crm.email.internal-pakket niet. Cruciaal is dat de module-info.java de verklaring provides com.crm.api.NotificationService with com.crm.email.internal.EmailNotificationService miste. Bijgevolg kon de ServiceLoader de provider niet lokaliseren of instantiëren, omdat het modulesysteem de implementatie als een ingekapseld intern detail beschouwde.
Overwogen oplossingen:
Het pakket exporteren: Het toevoegen van exports com.crm.email.internal; aan de descriptor van de crm-email-module. Deze aanpak werd afgewezen omdat het interne implementatiedetails aan alle andere modules zou blootstellen. Het zou de encapsulatie schenden en een sterke koppeling creëren die het modulesysteem juist wilde voorkomen.
Het pakket openen voor reflectie: Met opens com.crm.email.internal; of specifiek opens com.crm.email.internal to java.base;. Hoewel dit reflectieve toegang verleent, werd het als te permissief en semantisch onjuist beschouwd. Het geeft aan dat het pakket onderhevig is aan diepe reflectie in het algemeen, in plaats van specifiek een service via een gecontroleerd mechanisme te bieden.
Gebruik van de provides ... with-richtlijn: Het toevoegen van de verklaring provides com.crm.api.NotificationService with com.crm.email.internal.EmailNotificationService; aan de module-info.java. Dit is de idiomatische JPMS-oplossing. Het verklaart expliciet de service-relatie en verleent de ServiceLoader de nodige toegang om de klasse te instantiëren, terwijl de strikte encapsulatie behouden blijft.
Kies oplossing: Het team koos voor de derde optie. Deze aanpak vereiste geen wijzigingen aan de implementatiecode zelf. Het behield de interne zichtbaarheid van het pakket en maakte de dienstafhankelijkheid expliciet in de modulemetadata.
Resultaat: De applicatie laadde de EmailNotificationService succesvol tijdens runtime. De modulaire grens bleef intact, waardoor andere modules de interne implementatieklassen niet direct konden instantiëren of daarvan afhankelijk konden zijn. De ServiceLoader kon de service correct ontdekken en leveren via het verklaarde contract.
Waarom vereist de ServiceLoader dat de providerklasse een publieke zero-argumentconstructor heeft, en welke specifieke uitzondering verschijnt er als deze beperking wordt geschonden?
De ServiceLoader instantiëert providerklassen via reflectie met behulp van Class.getConstructor().newInstance(). Dit vereist strikt een publieke no-arg constructor. Als deze constructor afwezig is of niet publiek is, gooit de ServiceLoader een ServiceConfigurationError. Deze fout is meestal verpakt in een NoSuchMethodException of IllegalAccessException tijdens het itereren. Kandidaten vergeten vaak dat deze constructor expliciet moet worden opgegeven als er andere constructeurs zijn gedefinieerd. Ze missen ook dat de instantiatie lui plaatsvindt wanneer Iterator.next() wordt aangeroepen, niet tijdens de initiële ServiceLoader.load()-aanroep.
Hoe behandelt het ServiceLoader-mechanisme providerklassen die zich in niet-genaamde modules bevinden wanneer de service-interface is gedefinieerd binnen een genaamde module?
Wanneer een service-interface in een genaamde module verblijft, maar de implementatie in een niet-genaamde module (de classpath) bevindt, kan de ServiceLoader de provider nog steeds lokaliseren. Niet-genaamde modules lezen impliciet alle genaamde modules, en alle genaamde modules lezen impliciet niet-genaamde modules. De providerklasse moet echter nog steeds publiek zijn met een publieke no-arg constructor. De gangbare misvatting is dat sterke encapsulatie dit scenario volledig voorkomt. In werkelijkheid fungeert de niet-genaamde module als een compatibiliteitslaag. Providers in niet-genaamde modules kunnen niet worden benaderd door code in genaamde modules die de niet-genaamde module niet expliciet leest. Dit creëert een directionele toegankelijkheidsbeperking die kandidaten vaak over het hoofd zien.
Wat onderscheidt de ServiceLoader.loadInstalled()-methode van ServiceLoader.load() wat betreft klasse-loader-delegatie en zichtbaarheid van providers?
ServiceLoader.loadInstalled() gebruikt de systeemklasse-loader (of platformklasse-loader in moderne JVM-versies) om naar providers te zoeken. Het beperkt de ontdekking tot de geïnstalleerde extensiemap of platformmodules. Het negeert expliciet providers op het applicatiemodulepad of classpath. In tegenstelling daarmee gebruikt ServiceLoader.load() doorgaans de thread-contextklasse-loader of een specifieke klasse-loader. Dit stelt het in staat om applicatieniveau-providers te ontdekken. Kandidaten verwarren deze methoden vaak, wat leidt tot stille mislukkingen waarbij applicatieproviders niet worden gevonden. Dit gebeurt omdat loadInstalled() onjuist werd gebruikt, in de verwachting dat het zich zou gedragen als de standaard laadmethode, maar met bredere zichtbaarheid.