Java-Quickstart

In ein paar Minuten wertet dein Java-Service Feature Flags in-process aus — kein Netzwerk-Hop pro Prüfung, keine Latenz in deinem Request-Pfad, eine Abfrage versorgt jeden Request, den dein Prozess bedient.

Null Abhängigkeiten — JSON eingeschlossen: Das SDK bringt seinen eigenen kleinen Parser mit, sodass nichts Neues in deinen Abhängigkeitsbaum kommt. Es läuft auf Java 17 und neuer.

1. Installieren

Das SDK liegt in einem öffentlichen Repository auf GitHub — klone es am Release-Tag, baue es und binde es in deinen Build ein — zum Beispiel als Gradle Included Build oder indem du das Jar in dein internes Repository veröffentlichst:

git clone --branch v1.0.0 https://github.com/FortressFlag/FortressFlag_SDK_java
cd FortressFlag_SDK_java && ./gradlew build

2. Der Server-Schlüssel — ein echtes Geheimnis

Dieses SDK benutzt einen Server-Schlüssel (ffs_…), und der ist das Gegenteil der Client-Schlüssel, die die Mobil- und Web-SDKs ausliefern: Er kann dein vollständiges Ruleset herunterladen, Targeting-Regeln inklusive. Behandle ihn genau wie ein Datenbankpasswort — eine Umgebungsvariable oder ein Secret-Manager, nie Code, nie ein Repository, nie ein Log. Die zwei Schlüsselklassen, nebeneinander.

3. Starte den Client

import com.fortressflag.server.Client;
import com.fortressflag.server.Configuration;
import com.fortressflag.server.FortressFlag;
import java.time.Duration;

Client client = FortressFlag.create(
    Configuration.builder(System.getenv("FF_SERVER_KEY")).build());
// ^ die eine Stelle, an der das SDK wirft: ein fehlerhafter Schlüssel, bevor irgendetwas ausliefert.

client.start(Duration.ofSeconds(15)); // kehrt beim ersten Ruleset zurück (oder der Frist)

// ... dein Service läuft; Flag-Prüfungen sind jetzt In-Memory-Methodenaufrufe.

start wirft nie — wenn der erste Abruf nicht rechtzeitig landet, versucht der Client es auf seinem Hintergrund-Thread weiter, und deine Aufrufer bekommen inzwischen ihre Fallbacks. Der Poller läuft auf einem Daemon-Thread: Er hindert deine JVM nie am Beenden.

4. Werte ein Flag aus

import com.fortressflag.server.Context;
import java.util.Map;

boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // dein stabiler Kontext-Key: eine User-ID, eine Session-ID — deine Wahl
        Map.of("cohort", "beta")),
    false); // der Fallback, wenn das Flag unbekannt ist oder nie etwas abgerufen wurde

client.stringValue und client.numberValue funktionieren genauso. Der Kontext-Key ist das, worauf Prozent-Rollouts bucketen — übergib denselben Bezeichner konsistent, und jeder Nutzer bekommt eine stabile Kohorte. Es sind deine Daten: Das SDK validiert, speichert oder loggt sie nie.

Das war’s — dein Service wertet Flags lokal aus. Eine Dashboard-Änderung erreicht jeden Prozess innerhalb von etwa einer Minute.

Die Auswertung schlägt nie fehl

boolValue, stringValue und numberValue antworten immer und werfen nie — ein Flag-Problem darf deinen Service niemals lahmlegen. Ein neu gestarteter Prozess liefert deine Fallbacks von der Aufrufstelle, bis sein erster Abruf landet (oder setz cachePath am Builder, um das letzte Ruleset in einer Datei deiner Wahl zu persistieren, und Neustarts setzen sofort daraus fort). Selbst ein widerrufener Schlüssel macht nichts kaputt: Das SDK wertet mit dem zuletzt heruntergeladenen Ruleset weiter aus, bis du ihm einen neuen Schlüssel gibst.

Wie geht es weiter?

• Wie Flags deine App erreichen — die Server-Plane, erklärt
• Schlüssel — ffs_-Schlüssel erstellen, rotieren und widerrufen
• Targeting — die Regeln, die dein Service jetzt auswertet