Pular para conteúdo

0001 — Runtime Java 8 (exceção à constituição)

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-07-20 · Decidido em: 2026-07-20

Contexto

A constituição X-Adm manda Java 25 (LTS) para apps Java. O integrador-client, porém, roda on-premise na máquina do ERP, onde só existe JRE 8 instalado — e a equipe que mantém o ambiente desenvolve em ZIM, sem autonomia para atualizar o Java da máquina de produção do ERP.

Decisão

O alvo de runtime é Java 8 (bytecode 52): compileJava com --release 8 e Kotlin com jvmTarget 1.8. O build continua moderno: Gradle Kotlin DSL com toolchain JDK atual, CI no JDK 25 do setup-java do pipeline.yml (GitHub Actions, decisão central 0027; até set/2026 era a imagem ci-java:25 da fábrica, aposentada) — só o alvo é 8. O SDK PowerSync Kotlin JVM publica bytecode 1.8 e testa em launcher Java 8 no próprio CI, então a cadeia inteira é compatível. Dependências pinadas em linhas compatíveis com Java 8 (ex.: Logback 1.3.x, nunca 1.5.x).

Todo o resto da constituição permanece valendo (docs, gate ./gradlew check, checkstyle, release por tag com asset, §6).

Consequências

  • Código de produção sem APIs pós-8 (List.of, records, java.net.http…); testes podem usar o toolchain moderno pois não são empacotados.
  • Gate inclui verificação do bytecode (major 52) para flagrar regressão de alvo.
  • Quando o ERP migrar de Java, esta decisão cai e o repo volta ao padrão da casa.

Desvios do arquétipo (mesma raiz: legibilidade para a equipe ZIM)

Além do runtime, dois desvios conscientes do arquétipo "Java CLI/worker" da casa:

  • Sem picocli: o app tem 2 flags (--version, --debug) + um caminho opcional de properties — parsing manual de meia dúzia de linhas é mais legível para a equipe do que uma biblioteca de CLI; --version continua lendo do manifesto do build (nunca literal).
  • Sem flags ⇒ roda o daemon (não imprime help): este app é um worker residente, não um job de linha de comando — rodar é o comportamento esperado do operador; a validação fail-fast da configuração (exit 2 com a chave errada) cumpre o papel do "não falha calado".

Alternativas consideradas

  • Java 25 padrão — impossível: o jar não subiria no JRE 8 do cliente.
  • Empacotar JRE moderno junto (jlink/instalador) — aumenta o artefato e a superfície de operação na máquina do ERP; a equipe local não tem como dar suporte.
  • Port do SDK PowerSync para Java puro — inviável: o núcleo do protocolo vive na extensão Rust powersync-sqlite-core, sem spec pública (estimado 3–6 pessoa-meses).