Antwort

Reflection ist ein Mechanismus, der es ermöglicht, die Struktur und das Verhalten von Klassen, Objekten, Methoden und Feldern zur Laufzeit eines Programms zu untersuchen und zu ändern. Er wird durch das Paket java.lang.reflect implementiert.

Er ermöglicht:

• Informationen über Klassen zur Laufzeit zu erhalten
• Methoden dynamisch aufzurufen und auf Felder zuzugreifen
• Neue Instanzen von Klassen über ihren Namen zu erstellen

Beispiel:

import java.lang.reflect.Method;

public class ReflectionExample {
    public void greet() {
        System.out.println("Hallo!");
    }
    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); // Gibt aus: Hallo!
    }
}

Vorteile:

• Flexibilität und Erweiterbarkeit (z. B. Frameworks, DI)
• Möglichkeit von generischem Code für Operationen mit Objekten, ohne deren Typen im Voraus zu kennen

Nachteile/Risiken:

• Leistungseinbußen
• Potenzielle Sicherheitsprobleme (Umgehung von Zugriffsmodifikatoren)
• Bricht die Kapselung
• Geringere Wartbarkeit

Fangfrage

Ist es möglich, auf private Felder und Methoden einer Klasse über Reflection zuzugreifen, und was sind die Folgen davon?

Antwort: Ja, es ist möglich durch die Methode setAccessible(true) von Field oder Method:

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

Das verletzt die Kapselung der Klasse und birgt Risiken: Die Situation wird fragil, es können Sicherheitsfehler auftreten, und in neuen Versionen der JVM könnten solche Aktionen durch Zugriffsrichtlinien eingeschränkt werden.

Beispiele für echte Fehler aufgrund von Unkenntnis der Thematik

---

Geschichte

In einem großen Projekt zur automatischen Zuordnung von DTOs über Reflection wurden Felder des Typs "Optional" nicht richtig berücksichtigt, was zu NullPointerException bei der massenhaften Verarbeitung von Daten führte, da das Reflection-Paket zwischen Optional-Werten und null nicht unterschied.

---

Geschichte

In einer Banksoftware wurde der Zugriff auf private Felder über setAccessible(true) zur Serialisierung implementiert. Nach einem JVM-Update änderte sich das Verhalten, der Zugriff auf das private Feld wurde verweigert, und eine wichtige Funktionalität der Serialisierung funktionierte plötzlich nicht mehr in der Produktion.

---

Geschichte

In einem ORM-Framework wurde vergessen, den Cache der Reflection nach der Änderung des Datenschemas zu aktualisieren, was dazu führte, dass das System unvorhersehbare Ausnahmen bei der Arbeit mit neuen Klassenfeldern ausgab, die nicht im Cache reflektiert wurden.