Quickstart Java

In pochi minuti il tuo servizio Java valuterà i feature flag in-process — nessun salto di rete per controllo, nessuna latenza nel percorso delle tue richieste, un solo poll che serve ogni richiesta gestita dal tuo processo.

Zero dipendenze — JSON incluso: l’SDK porta con sé il proprio piccolo parser, così nulla di nuovo entra nel tuo albero delle dipendenze. Gira su Java 17 e successivi.

1. Installa

L’SDK vive in un repository pubblico su GitHub — clonalo al tag della release, compilalo e includilo nella tua build — per esempio come included build Gradle o pubblicando il jar nel tuo repository interno:

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

2. La chiave server — un segreto vero e proprio

Questo SDK usa una chiave server (ffs_…), ed è l’opposto delle chiavi client che gli SDK mobile e web portano con sé: può scaricare il tuo ruleset completo, regole di targeting incluse. Trattala esattamente come la password di un database — una variabile d’ambiente o un secret manager, mai il codice, mai un repository, mai un log. Le due classi di chiavi, fianco a fianco.

3. Avvia il 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());
// ^ l'unico punto in cui l'SDK lancia un'eccezione: una chiave malformata, prima che qualsiasi cosa venga servita.

client.start(Duration.ofSeconds(15)); // ritorna al primo ruleset (o alla scadenza)

// ... il tuo servizio gira; i controlli dei flag ora sono chiamate di metodo in memoria.

start non lancia mai eccezioni — se il primo fetch non riesce ad arrivare in tempo, il client continua a riprovare sul suo thread in background e nel frattempo i tuoi chiamanti ricevono i loro fallback. Il poller gira su un thread daemon: non impedisce mai alla tua JVM di terminare.

4. Valuta un flag

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

boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // la tua chiave di contesto stabile: un id utente, un id sessione — scegli tu
        Map.of("cohort", "beta")),
    false); // il fallback se il flag è sconosciuto o non è mai stato scaricato nulla

client.stringValue e client.numberValue funzionano allo stesso modo. La chiave del contesto è ciò su cui i rollout percentuali fanno il bucketing — passa lo stesso identificatore in modo coerente e ogni utente riceve una coorte stabile. Sono dati tuoi: l’SDK non li valida, memorizza o registra mai.

Fatto — il tuo servizio sta valutando i flag in locale. Una modifica nella dashboard raggiunge ogni processo entro circa un minuto.

La valutazione non fallisce mai

boolValue, stringValue e numberValue rispondono sempre e non lanciano mai eccezioni — un problema con i flag non deve mai buttare giù il tuo servizio. Un processo riavviato serve i fallback dei tuoi punti di chiamata finché non arriva il primo fetch (oppure imposta cachePath sul builder per persistere l’ultimo ruleset in un file a tua scelta, e i riavvii riprendono da lì all’istante). Nemmeno una chiave revocata rompe qualcosa: l’SDK continua a valutare con l’ultimo ruleset scaricato finché non gli consegni una nuova chiave.

Prossimi passi

• Come i flag raggiungono la tua app — il piano server, spiegato
• Chiavi — genera, ruota e revoca le chiavi ffs_
• Targeting — le regole che il tuo servizio sta ora valutando