Quickstart de Java

Em poucos minutos o seu serviço em Java vai avaliar feature flags in-process — sem salto de rede por verificação, sem latência no caminho das suas requisições, um polling atendendo toda requisição que o seu processo trata.

Zero dependências — inclusive JSON: o SDK carrega o próprio parser pequeno, então nada de novo entra na sua árvore de dependências. Ele roda no Java 17 e posteriores.

1. Instale

O SDK mora em um repositório público no GitHub — clone-o na tag da release, compile-o e inclua-o no seu build — por exemplo como um included build do Gradle ou publicando o jar no seu repositório interno:

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

2. A chave de servidor — um segredo de verdade

Este SDK usa uma chave de servidor (ffs_…), e ela é o oposto das chaves de cliente que os SDKs de mobile e web carregam: ela consegue baixar o seu ruleset completo, regras de segmentação incluídas. Trate-a exatamente como uma senha de banco de dados — uma variável de ambiente ou um gerenciador de segredos, nunca código, nunca um repositório, nunca um log. As duas classes de chave, lado a lado.

3. Inicie o cliente

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());
// ^ o único lugar em que o SDK lança exceção: uma chave malformada, antes de qualquer coisa ser servida.

client.start(Duration.ofSeconds(15)); // retorna no primeiro ruleset (ou no prazo)

// ... o seu serviço roda; verificações de flag agora são chamadas de método em memória.

start nunca lança exceção — se a primeira busca não conseguir chegar a tempo, o cliente continua tentando na thread em segundo plano e quem chama recebe os fallbacks enquanto isso. O poller roda em uma thread daemon: ele nunca impede a sua JVM de sair.

4. Avalie uma flag

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

boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // a sua chave de contexto estável: um id de usuário, um id de sessão — você escolhe
        Map.of("cohort", "beta")),
    false); // o fallback se a flag for desconhecida ou nada tiver sido buscado ainda

client.stringValue e client.numberValue funcionam do mesmo jeito. A chave de contexto é o que os rollouts percentuais usam para distribuir — passe o mesmo identificador de forma consistente e cada usuário recebe uma coorte estável. É dado seu: o SDK nunca valida, armazena nem registra isso em log.

É isso — o seu serviço está avaliando flags localmente. Uma mudança no painel chega a todo processo em cerca de um minuto.

A avaliação nunca falha

boolValue, stringValue e numberValue sempre respondem e nunca lançam exceção — um problema com flags nunca pode derrubar o seu serviço. Um processo reiniciado serve os fallbacks do ponto de chamada até a primeira busca chegar (ou defina cachePath no builder para persistir o último ruleset em um arquivo à sua escolha, e os reinícios retomam dele instantaneamente). Nem uma chave revogada quebra nada: o SDK continua avaliando com o último ruleset que baixou até você entregar uma chave nova.

Para onde ir agora

• Como as flags chegam ao seu app — o server plane, explicado
• Chaves — crie, rotacione e revogue chaves ffs_
• Segmentação — as regras que o seu serviço agora está avaliando