Skip to content
FortressFlag Docs

Java quickstart

In a few minutes your Java service will evaluate feature flags in-process — no network hop per check, no latency in your request path, one poll serving every request your process handles.

Zero dependencies — including JSON: the SDK carries its own small parser, so nothing new enters your dependency tree. It runs on Java 17 and later.

1. Install

Section titled “1. Install”

The SDK is pre-release and its repository isn’t public yet. If your team has been given access, build it from the repository and include it in your build — for example as a Gradle included build or by publishing the jar to your internal repository:

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

2. The server key — a genuine secret

Section titled “2. The server key — a genuine secret”

This SDK uses a server key (ffs_…), and it’s the opposite of the client keys the mobile and web SDKs ship: it can download your full ruleset, targeting rules included. Treat it exactly like a database password — an environment variable or a secret manager, never code, never a repository, never a log. The two key classes, side by side.

3. Start the client

Section titled “3. Start the 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());
// ^ the one place the SDK throws: a malformed key, before anything serves.


client.start(Duration.ofSeconds(15)); // returns at the first ruleset (or the deadline)


// ... your service runs; flag checks are now in-memory method calls.

start never throws — if the first fetch can’t land in time, the client keeps trying on its background thread and your callers get their fallbacks meanwhile. The poller runs on a daemon thread: it never blocks your JVM from exiting.

4. Evaluate a flag

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


boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // your stable context key: a user id, a session id — your choice
        Map.of("cohort", "beta")),
    false); // the fallback if the flag is unknown or nothing was ever fetched

client.stringValue and client.numberValue work the same way. The context key is what percentage rollouts bucket on — pass the same identifier consistently and each user gets a stable cohort. It’s your data: the SDK never validates, stores, or logs it.

That’s it — your service is evaluating flags locally. A dashboard change reaches every process within about a minute.

Evaluation never fails

Section titled “Evaluation never fails”

boolValue, stringValue, and numberValue always answer and never throw — a flagging problem must never take down your service. A restarted process serves your call-site fallbacks until its first fetch lands (or set cachePath on the builder to persist the last ruleset to a file of your choosing, and restarts resume from it instantly). Even a revoked key doesn’t break anything: the SDK keeps evaluating with the last ruleset it downloaded until you hand it a new key.

Where to next

Section titled “Where to next”