Antwoord

Reflectie is een mechanisme dat het mogelijk maakt om de structuur en het gedrag van klassen, objecten, methoden en velden tijdens de uitvoering van een programma te onderzoeken en te wijzigen. Dit wordt geïmplementeerd via het pakket java.lang.reflect.

Het stelt je in staat om:

• Informatie over klassen tijdens de uitvoering te verkrijgen
• Methodes aan te roepen en dynamisch toegang te krijgen tot velden
• Nieuwe instanties van klassen op naam te creëren

Voorbeeld:

import java.lang.reflect.Method;

public class ReflectionExample {
    public void greet() {
        System.out.println("Hello!");
    }
    public static void main(String[] args) throws Exception {
        Class<?> clazz = Class.forName("ReflectionExample");
        Object instance = clazz.getDeclaredConstructor().newInstance();
        Method method = clazz.getMethod("greet");
        method.invoke(instance); // Zal afdrukken: Hello!
    }
}

Voordelen:

• Flexibiliteit en uitbreidbaarheid (bijvoorbeeld frameworks, DI)
• Mogelijkheid voor generieke code voor bewerkingen met objecten, zonder hun types van tevoren te kennen

Nadelen/risico's:

• Verminderde prestaties
• Potentiële beveiligingsproblemen (omzeilen van toegangsmodifiers)
• Breekt encapsulatie
• Lagere onderhoudbaarheid

Misleidende vraag

Is het mogelijk om toegang te krijgen tot private velden en methoden van een klasse met behulp van reflectie, en wat zijn de gevolgen hiervan?

Antwoord: Ja, dit is mogelijk met behulp van de methode setAccessible(true) op Field of Method:

Field field = clazz.getDeclaredField("privateField");
field.setAccessible(true);
field.set(obj, "value");

Dit schendt de encapsulatie van de klasse en brengt risico's met zich mee: de situatie wordt fragiel, er kunnen beveiligingsfouten optreden, en in nieuwe versies van de JVM kunnen dergelijke acties beperkt worden door toegangsbeleid.

Voorbeelden van werkelijke fouten door onwetendheid over de subtiliteiten van het onderwerp

---

Verhaal

In een groot project voor automatische mapping van DTO's via reflectie werden velden van het type "Optional" niet correct afgehandeld, wat leidde tot een NullPointerException bij massadataverwerking, omdat het reflectiepakket geen onderscheid maakte tussen Optional-waarden en null.

---

Verhaal

In bancaire software werd toegang tot private velden gerealiseerd via setAccessible(true) voor serialisatie. Na een update van de JVM veranderde het gedrag, de toegang tot het private veld bleek gesloten te zijn, en belangrijke serialisatiefunctionaliteit stopte plotseling met werken in productie.

---

Verhaal

In een ORM-framework vergat ik de reflectiecache bij te werken na een wijziging in het datamodel. Als gevolg daarop gaf het systeem onvoorspelbare uitzonderingen weer bij het werken met nieuwe klassenvelden die niet in de cache waren weergegeven.