Aller au contenu
FortressFlag Docs

Guide de démarrage Java

En quelques minutes, votre service Java évaluera des feature flags in-process — aucun saut réseau par vérification, aucune latence sur le chemin de vos requêtes, un seul polling servant chaque requête que votre processus traite.

Zéro dépendance — JSON compris : le SDK embarque son propre petit analyseur, donc rien de nouveau n’entre dans votre arbre de dépendances. Il fonctionne sur Java 17 et ultérieur.

1. Installez

Section intitulée « 1. Installez »

Le SDK vit dans un dépôt public sur GitHub — clonez-le au tag de la version publiée, compilez-le et incluez-le dans votre build — par exemple comme un included build Gradle ou en publiant le jar dans votre dépôt interne :

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

2. La clé serveur — un vrai secret

Section intitulée « 2. La clé serveur — un vrai secret »

Ce SDK utilise une clé serveur (ffs_…), et c’est l’opposé des clés client embarquées par les SDK mobiles et web : elle peut télécharger votre ruleset complet, règles de ciblage incluses. Traitez-la exactement comme un mot de passe de base de données — une variable d’environnement ou un gestionnaire de secrets, jamais du code, jamais un dépôt, jamais un journal. Les deux classes de clés, côte à côte.

3. Démarrez le client

Section intitulée « 3. Démarrez le 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());
// ^ le seul endroit où le SDK lève une exception : une clé malformée, avant que quoi que ce soit ne serve.


client.start(Duration.ofSeconds(15)); // rend la main au premier ruleset (ou à l’échéance)


// ... votre service tourne ; les vérifications de flags sont désormais des appels de méthode en mémoire.

start ne lève jamais d’exception — si la première récupération ne peut pas aboutir à temps, le client continue d’essayer sur son thread d’arrière-plan et vos appelants reçoivent leurs replis entre-temps. Le poller tourne sur un thread démon : il n’empêche jamais votre JVM de se terminer.

4. Évaluez un flag

Section intitulée « 4. Évaluez un flag »
import com.fortressflag.server.Context;
import java.util.Map;


boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // votre clé de contexte stable : un id d’utilisateur, un id de session — à vous de choisir
        Map.of("cohort", "beta")),
    false); // le repli si le flag est inconnu ou si rien n’a jamais été récupéré

client.stringValue et client.numberValue fonctionnent de la même façon. La clé de contexte est ce sur quoi les déploiements progressifs répartissent — passez le même identifiant de façon cohérente et chaque utilisateur obtient une cohorte stable. Ce sont vos données : le SDK ne les valide, ne les stocke ni ne les journalise jamais.

C’est tout — votre service évalue les flags localement. Un changement dans le tableau de bord atteint chaque processus en une minute environ.

L’évaluation n’échoue jamais

Section intitulée « L’évaluation n’échoue jamais »

boolValue, stringValue et numberValue répondent toujours et ne lèvent jamais d’exception — un problème de flags ne doit jamais faire tomber votre service. Un processus redémarré sert les replis de vos points d’appel jusqu’à ce que sa première récupération aboutisse (ou définissez cachePath sur le builder pour persister le dernier ruleset dans un fichier de votre choix, et les redémarrages reprennent depuis celui-ci instantanément). Même une clé révoquée ne casse rien : le SDK continue d’évaluer avec le dernier ruleset qu’il a téléchargé jusqu’à ce que vous lui donniez une nouvelle clé.

Où aller ensuite

Section intitulée « Où aller ensuite »