Domain-Driven Design ohne Performance-Verlust: Was Project Valhalla für Java bedeutet

Wer schon mal mit Domain-Driven Design in Java gearbeitet hat, kennt das Problem. Man möchte Typsicherheit schaffen – zum Beispiel ein PositiveInt, das niemals negativ sein darf. Der Compiler soll ungültige Zustände abweisen. Das klingt gut, bis der Code auf einen Hot Path trifft. Dann wird aus der sauberen Abstraktion plötzlich ein Flaschenhaken.

Bisher: Zu viel Overhead für zu wenig Nutzen

Ein einfaches Wrapper-Objekt, das nur einen int enthält, belegt auf HotSpot rund 16 Byte. In einem Array mit einer Million Einträgen speichert Java nicht die Werte direkt, sondern nur Verweise auf die Objekte. Jeder Zugriff bedeutet einen Pointer-Dereferenz und potenziell einen Cache-Miss. Der Speicherverbrauch vervierfacht sich, die Performance leidet.

Viele Entwickler haben deshalb einen Kompromiss gewählt: Typensicherheit nur an den Rändern des Systems, im Inneren dann wieder primitive Typen. Sauber war das nie.

Value Classes bringen die Lösung

Mit Project Valhalla und dem neuen value Keyword ändert sich das. Value Classes verhalten sich wie Primitives: Sie haben keine Identität und werden vom JVM nicht als eigenständige Objekte auf dem Heap angelegt. Stattdessen legt die JVM sie direkt in Arrays, Feldern oder sogar Registern ab.

Das Beispiel aus dem Quelltext sieht so aus:

public value class PositiveInt {
    private final int value;

    public PositiveInt(int value) {
        if (value <= 0) {
            throw new IllegalArgumentException("must be positive: " + value);
        }
        this.value = value;
    }

    public int value() { 
        return value; 
    }
}

Der Konstruktor läuft weiterhin, die Validierung bleibt erhalten – nur die Speicherstruktur ändert sich. Der JVM steht jetzt frei, die Klasse zu „flachen“.

Auch komplexere Strukturen profitieren

Nicht nur einfache Wrapper profitieren. Ein Coordinate mit Latitude und Longitude lässt sich mit Value Classes ohne Indirektionen speichern. 16 Byte kontinuierlicher Daten statt drei Ebenen von Pointern. Bei Anwendungen mit vielen Geodaten – etwa bei Location-Tracking oder Wetteranalysen – wirkt sich das stark auf die Geschwindigkeit aus.

Praktisches Beispiel aus der Domain-Welt

Bei NameOcean geht es täglich um Domain-Namen und TLDs. Bisher musste man an der API-Grenze prüfen und dann intern mit String oder int arbeiten. Mit Value Classes lässt sich das ändern:

public value class DomainName {
    private final String value;

    public DomainName(String value) {
        if (!isValidDomain(value)) {
            throw new IllegalArgumentException("Invalid domain: " + value);
        }
        this.value = value;
    }
}

Jetzt lässt sich der gesamte DNS-Prozess mit typensicher<|eos|>