Ga naar inhoud
FortressFlag Docs

Java-quickstart

Binnen een paar minuten evalueert je Java-service feature flags in-process — geen netwerkstap per controle, geen latentie in je verzoekpad, één poll die elk verzoek bedient dat je proces afhandelt.

Nul dependencies — inclusief JSON: de SDK draagt zijn eigen kleine parser, dus er komt niets nieuws in je dependency-tree. Hij draait op Java 17 en later.

1. Installeren

Section titled “1. Installeren”

De SDK is pre-release en zijn repository is nog niet publiek. Heeft je team toegang gekregen, bouw hem dan uit de repository en neem hem op in je build — bijvoorbeeld als Gradle-included build of door de jar naar je interne repository te publiceren:

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

2. De serversleutel — een echt geheim

Section titled “2. De serversleutel — een echt geheim”

Deze SDK gebruikt een serversleutel (ffs_…), en die is het tegenovergestelde van de clientsleutels die de mobiele en web-SDK’s meesturen: hij kan je volledige ruleset downloaden, targetingregels inbegrepen. Behandel hem precies als een databasewachtwoord — een omgevingsvariabele of een secret manager, nooit code, nooit een repository, nooit een log. De twee sleutelklassen, naast elkaar.

3. Start de client

Section titled “3. Start de 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());
// ^ de ene plek waar de SDK gooit: een misvormde sleutel, voordat er iets serveert.


client.start(Duration.ofSeconds(15)); // keert terug bij de eerste ruleset (of de deadline)


// ... je service draait; flagcontroles zijn nu methodeaanroepen in het geheugen.

start gooit nooit — kan de eerste fetch niet op tijd landen, dan blijft de client het op zijn achtergrondthread proberen en krijgen je aanroepers intussen hun fallbacks. De poller draait op een daemon-thread: hij houdt je JVM nooit tegen bij het afsluiten.

4. Evalueer een flag

Section titled “4. Evalueer een flag”
import com.fortressflag.server.Context;
import java.util.Map;


boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // je stabiele contextsleutel: een gebruikers-id, een sessie-id — jouw keuze
        Map.of("cohort", "beta")),
    false); // de fallback als de flag onbekend is of er nooit iets is opgehaald

client.stringValue en client.numberValue werken op dezelfde manier. De contextsleutel is waar percentage-rollouts op bucketten — geef consequent dezelfde identifier mee en elke gebruiker krijgt een stabiel cohort. Het zijn jouw gegevens: de SDK valideert, bewaart of logt ze nooit.

Dat is het — je service evalueert flags lokaal. Een dashboardwijziging bereikt elk proces binnen ongeveer een minuut.

Evaluatie faalt nooit

Section titled “Evaluatie faalt nooit”

boolValue, stringValue en numberValue geven altijd antwoord en gooien nooit — een flagprobleem mag nooit je service neerhalen. Een herstart proces serveert je fallbacks van de aanroepplek tot zijn eerste fetch landt (of zet cachePath op de builder om de laatste ruleset naar een bestand naar keuze te bewaren, en herstarts hervatten er onmiddellijk uit). Zelfs een ingetrokken sleutel breekt niets: de SDK blijft evalueren met de laatst gedownloade ruleset tot je hem een nieuwe sleutel geeft.

Waar nu heen?

Section titled “Waar nu heen?”