Java 1.1 introduceerde blank final variabelen—velden die als final zijn gedeclareerd zonder initializer—om flexibele onveranderlijke patronen te ondersteunen zonder onmiddellijke toewijzing op de declaratieplaats af te dwingen. Het fundamentele probleem is ervoor te zorgen dat deze velden precies één keer worden toegewezen op elk mogelijk uitvoeringspad voordat ze worden gebruikt, een uitdaging die wordt bemoeilijkt door try-catch blokken, vertakkingslogica en vroege returns die de initialisatie mogelijk omzeilen. Om dit op te lossen, voert de compiler Definite Assignment (DA) analyse uit op de controle-stroomgrafiek (CFG), waarbij een set variabelen wordt gevolgd die op elk programmapunt zeker zijn toegewezen; voor finals voert hij bovendien Definite Unassignment (DU) analyse uit om te garanderen dat het veld niet twee keer wordt geschreven. De bytecode verifier handhaaft deze beperkingen bij het laden van de klasse via de StackMapTable attribuut en typechecking, waardoor wordt gegarandeerd dat geen instructie een variabele kan lezen die niet zeker is toegewezen.
Een team van financiële diensten bouwde een ImmutableTrade klasse met een final UUID tradeId dat werd gegenereerd via een externe service-aanroep binnen de constructor. De constructor omhulde deze oproep in een try-catch om ServiceUnavailableException te behandelen, de fout te loggen en opnieuw te gooien, maar slaagde er niet in tradeId toe te wijzen in de catch block, wat een compilatiefout veroorzaakte omdat de Definite Assignment analyse van de compiler ontdekte dat het uitzonderlijke pad het final veld niet geïnitialiseerd had gelaten.
Een voorgestelde oplossing was het initialiseren van tradeId op null in de catch block, maar dit voldeed niet aan de bedrijfsinvariant dat elke ImmutableTrade een geldige identificatie moet hebben, wat mogelijk een NullPointerException downstream zou kunnen veroorzaken en het doel van de garanties van het final veld zou ondermijnen. Een andere aanpak betrof het gebruik van een boolean vlag om de status van de toewijzing bij te houden, maar dit voegde veranderlijke status en onnodige complexiteit toe, waardoor de onveranderlijkheid en threadveiligheid die het team probeerde te bereiken, werden ondermijnd. Het team koos uiteindelijk voor het refactoren naar een static factory pattern, waarbij de service-aanroep extern werd uitgevoerd en de resulterende UUID aan een privé constructor werd doorgegeven, waarmee werd gegarandeerd dat het veld precies één keer met een geldige waarde zeker werd toegewezen.
Deze benadering voldeed aan de strenge DA-analyse van de compiler zonder dat dummywaarden vereist waren en behield de contractuele onveranderlijkheid van de klasse, terwijl deze ook voorafvalidatie en caching van service-resultaten mogelijk maakte. De resulterende codebase voldeed aan de compilatie en rigoureuze stresstests, wat aantoonde dat naleving van de regels voor definitieve toewijzing potentiële NullPointerException scenario's in productie voorkwam en veilige deling van ImmutableTrade objecten over gelijktijdige threads zonder synchronisatie-overhead mogelijk maakte.
Kan reflectie een final veld wijzigen na de constructie, en waarom kunnen dergelijke wijzigingen onzichtbaar blijven voor andere code?
Reflectie kan instance final velden wijzigen met Field#setAccessible(true) en set(), maar static final velden die zijn geïnitialiseerd met compile-tijd constante (primitieven of Strings) worden door de compiler als letterlijke waarden in de client bytecode ingelijnd. Gevolg hiervan is dat reflectieve wijzigingen aan dergelijke constanten onzichtbaar zijn voor al gecompileerde klassen, die de constante poolinvoer eerder dan het veld aanroepen. Bovendien beschouwt de JVM werkelijk final velden als onveranderlijk voor optimalisatie, wat VarHandle met private lookup of Unsafe vereist om wijzigingen af te dwingen, en zelfs dan kunnen CPU-caches de wijziging mogelijk niet waarnemen zonder expliciete geheugenbarrières, wat leidt tot subtiele zichtbaarheidfouten.
Hoe beïnvloedt het ontsnappen van de 'this' referentie tijdens de constructie de garanties voor definitieve toewijzing van final velden?
Zelfs wanneer DA-analyse bevestigt dat een final veld is toegewezen voordat de constructor terugkeert, creëert het publiceren van this naar een andere thread tijdens de constructie (bijvoorbeeld via een listener of register) een raceconditie waarbij de andere thread mogelijk de standaardwaarde (nul) kan observeren als gevolg van instructieherordening. Het Java Memory Model garandeert dat alle threads na de voltooiing van de constructor de waarde van het final veld correct zien, maar het biedt geen dergelijke garantie tijdens de constructie. Daarom is definitieve toewijzing strikt een statische compile-tijd eigenschap die enkele toewijzing waarborgt, terwijl veilige publicatie vereist dat this niet uit de constructor ontsnapt voordat alle final velden zijn opgeslagen.
Waarom weigert de compiler toewijzing aan een blank final veld binnen een lus, zelfs als de logica suggereert dat het precies één keer wordt uitgevoerd?
De compiler voert een conservatieve statische analyse uit en kan niet bewijzen dat een lus precies één keer uitvoert of dat deze niet nul keer iteraties uitvoert; lussen introduceren back-edges in de controle-stroomgrafiek die het bijhouden van DA bemoeilijken. Omdat een final veld precies één keer moet worden toegewezen, schendt de mogelijkheid van meerdere iteraties (meerdere toewijzingen) of nul iteraties (geen toewijzing) de Definite Unassignment invariant die vereist is voor blank finals. Bijgevolg verplicht de compiler dat toewijzing aan blank finals plaatsvindt buiten lussen of in vertakkingen met ondubbelzinnige enkele toewijzingsemantiek, en verwerpt code die mensen logisch zouden kunnen verifiëren maar die de CFG niet kan garanderen.