Guía rápida de Java

En unos minutos tu servicio en Java evaluará feature flags en el propio proceso — sin salto de red por comprobación, sin latencia en tu ruta de petición, un solo sondeo sirviendo a cada petición que atiende tu proceso.

Cero dependencias — JSON incluido: el SDK lleva su propio analizador pequeño, así que nada nuevo entra en tu árbol de dependencias. Funciona en Java 17 y posteriores.

1. Instala

El SDK vive en un repositorio público en GitHub — clónalo en la etiqueta de la versión publicada, compílalo e inclúyelo en tu build — por ejemplo como un build incluido de Gradle o publicando el jar en tu repositorio interno:

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

2. La clave de servidor — un secreto de verdad

Este SDK usa una clave de servidor (ffs_…), y es lo contrario de las claves de cliente que llevan los SDK móviles y web: puede descargar tu ruleset completo, reglas de targeting incluidas. Trátala exactamente como una contraseña de base de datos — una variable de entorno o un gestor de secretos, nunca código, nunca un repositorio, nunca un log. Las dos clases de claves, lado a lado.

3. Arranca el 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());
// ^ el único sitio en el que el SDK lanza una excepción: una clave mal formada, antes de que nada se sirva.

client.start(Duration.ofSeconds(15)); // vuelve con el primer ruleset (o al vencer el plazo)

// ... tu servicio se ejecuta; las comprobaciones de flags son ahora llamadas a métodos en memoria.

start nunca lanza excepciones — si la primera descarga no puede llegar a tiempo, el cliente sigue intentándolo en su hilo de segundo plano y quienes te llaman reciben sus respaldos mientras tanto. El sondeador corre en un hilo daemon: nunca impide que tu JVM salga.

4. Evalúa un flag

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

boolean enabled = client.boolValue(
    "new-checkout",
    new Context(
        "user-42", // tu clave de contexto estable: un id de usuario, un id de sesión — tú eliges
        Map.of("cohort", "beta")),
    false); // el respaldo si el flag es desconocido o nunca se descargó nada

client.stringValue y client.numberValue funcionan igual. La clave de contexto es sobre lo que reparten los rollouts porcentuales — pasa el mismo identificador de forma consistente y cada usuario obtiene una cohorte estable. Son tus datos: el SDK nunca los valida, almacena ni registra.

Eso es todo — tu servicio está evaluando flags localmente. Un cambio en el panel llega a cada proceso en aproximadamente un minuto.

La evaluación nunca falla

boolValue, stringValue y numberValue siempre responden y nunca lanzan excepciones — un problema con los flags nunca debe tumbar tu servicio. Un proceso reiniciado sirve tus respaldos del punto de llamada hasta que llega su primera descarga (o pon cachePath en el builder para persistir el último ruleset en un archivo que elijas, y los reinicios se reanudan desde él al instante). Ni siquiera una clave revocada rompe nada: el SDK sigue evaluando con el último ruleset que descargó hasta que le des una clave nueva.

¿Por dónde seguir?

• Cómo llegan los flags a tu app — el plano de servidor, explicado
• Claves — emite, rota y revoca claves ffs_
• Targeting — las reglas que tu servicio está evaluando ahora