Forem: Luis Fabrício De Llamas

Java 26: o que são Lazy Constants e por que elas aposentam o double-checked locking (JEP 526)

Luis Fabrício De Llamas — Fri, 03 Apr 2026 17:28:01 +0000

O Java 26 trouxe o JEP 526: Lazy Constants. Uma forma nativa e thread-safe de inicializar um valor uma única vez, só quando ele for usado de verdade. Aquele synchronized com double-checked locking que você escreveu há anos? Agora tem alternativa de primeira classe.

O que é o JEP 526 do Java 26?

O JEP 526 traz a classe java.lang.LazyConstant<T>: um container que guarda um valor imutável, inicializado no máximo uma vez. No Java 25, a feature se chamava "Stable Values" (JEP 502). No Java 26, foi renomeada, ganhou uma API mais simples e entrou em second preview.

O problema que ela resolve é antigo: campos final garantem imutabilidade, mas exigem inicialização imediata. Campos não-final permitem inicialização tardia, mas perdem as garantias de concorrência. LazyConstant junta os dois mundos: você inicializa quando quiser, mas só uma vez, com a mesma segurança de um final.

Por que o double-checked locking existe e qual é o problema?

Todo dev Java já escreveu algo assim:

public class MetricRegistry {

    private static volatile MetricRegistry instance;

    public static MetricRegistry getInstance() {
        if (instance == null) {
            synchronized (MetricRegistry.class) {
                if (instance == null) {
                    instance = new MetricRegistry();
                }
            }
        }
        return instance;
    }
}

Funciona. Mas exige volatile, dois null checks e um synchronized. Quem lê pela primeira vez não entende rápido. A alternativa com classe interna estática é mais segura, mas continua sendo um workaround.

Nenhuma dessas opções é uma abstração de primeira classe pro problema real: "inicialize isso uma vez, quando precisar, de forma segura".

Como o LazyConstant funciona na prática?

Imagine um serviço de pagamento com um cliente HTTP caro de criar, que só faz sentido existir se a rota for chamada:

public class PaymentService {

    private final LazyConstant<HttpClient> httpClient =
        LazyConstant.of(() -> HttpClient.newBuilder()
            .connectTimeout(Duration.ofSeconds(5))
            .build());

    public String charge(String orderId, BigDecimal amount) {
        HttpClient client = httpClient.get();
        // usa o client para chamar o gateway
    }
}

O HttpClient só é criado na primeira chamada a httpClient.get(). Depois disso, a JVM retorna o mesmo valor e pode até aplicar constant-folding. Thread-safe por construção, sem synchronized, sem volatile.

O que mudou do Java 25 para o Java 26 no JEP 526?

No Java 25, a API coloca métodos de baixo nível como setOrThrow, trySet e orElseSet, o que transformava a coisa num primitivo de sincronização. Ia contra o objetivo da feature.

No Java 26, ficou só o LazyConstant.of(supplier). Você fornece a função de inicialização e a JVM cuida do resto.

As factory methods para listas e mapas lazy também mudaram de lugar, saindo de StableValue para List e Map diretamente:

// Lista lazy com 10 slots, cada um inicializado de forma independente
List<OrderProcessor> processors = List.ofLazy(10, _ -> new OrderProcessor());

// Mapa lazy com chaves definidas, valores inicializados sob demanda
Map<String, RateLimiter> limiters = Map.ofLazy(
    Set.of("payments", "refunds", "reports"),
    key -> RateLimiter.create(requestsPerSecond(key))
);

Cada slot da lista e cada entry do mapa tem seu próprio ciclo de inicialização. O slot payments pode existir sem que refunds tenha sido criado.

Qual é a diferença entre LazyConstant e um campo final normal?

Um campo final exige que o valor exista na construção do objeto. Nem sempre isso é possível: a dependência pode não estar pronta, a inicialização pode ser cara demais pro startup, ou o valor depende de algo que só acontece depois.

// final obriga inicialização imediata
private final ExpensiveClient client = new ExpensiveClient(); // roda no construtor

// LazyConstant inicializa na primeira chamada a .get()
private final LazyConstant<ExpensiveClient> client =
    LazyConstant.of(ExpensiveClient::new);

Depois de inicializado, a JVM pode tratar o LazyConstant como constante e aplicar as mesmas otimizações de um final estático.

O que preciso saber antes de usar Lazy Constants no Java 26?

Ainda é preview. Para compilar e rodar, você precisa de --enable-preview:

javac --enable-preview --release 26 PaymentService.java
java --enable-preview PaymentService

LazyConstant não é Serializable. Se você precisa serializar o objeto, não vai funcionar.

O valor do container é imutável, mas o objeto dentro pode não ser. O LazyConstant garante que a referência é atribuída uma vez. O que você faz com o objeto depois é problema seu.

Quando usar e quando não usar LazyConstant?

Use quando o objeto é caro de criar, nem sempre necessário e precisa ser thread-safe sem que você gerencie sincronização na mão. Conexões de banco, clients HTTP, caches de configuração, registros de métricas.

Não use quando um final comum resolve, quando precisa de serialização, ou quando quer controle exato de quando a inicialização acontece. LazyConstant garante que ela ocorre antes do primeiro .get(), mas não no momento específico que você escolher.

Por que isso importa agora, sendo ainda preview?

O double-checked locking está em produção em milhares de sistemas Java. Não porque alguém goste da complexidade, mas porque não tinha alternativa melhor. O JEP 526 é a resposta do OpenJDK pra isso.

Pode mudar antes de ser finalizado. A segunda preview serve pra isso. Mas a direção é clara: a plataforma quer tratar esse padrão como abstração de primeira classe, com suporte do compilador e da JVM, não como receita de código que cada dev implementa do seu jeito.

Experimentar agora com --enable-preview é a forma mais direta de entender o impacto no seu código antes que a feature chegue como estável.

Perguntas frequentes sobre LazyConstant e JEP 526 no Java 26

LazyConstant é thread-safe?
Sim. A inicialização única vale em ambientes multithread sem precisar de synchronized ou volatile.

Posso usar LazyConstant com Serializable?
Não. Se o objeto precisa de serialização, use final ou outro mecanismo.

LazyConstant substitui o padrão Singleton com classe interna estática?
Pra maioria dos casos, sim. O resultado é o mesmo, mas o código fica mais direto e a intenção fica explícita no tipo.

Preciso de Java 26 para usar essa feature?
Sim, com --enable-preview. O JEP 526 é second preview e ainda não é estável.

O que acontece se a função de inicialização lançar uma exceção?
A exceção é propagada pra quem chamou .get() e o LazyConstant não fica marcado como inicializado. A próxima chamada tenta de novo.

Eu sou o Luis De Llamas, Developer Advocate na act digital, Oracle ACE e IBM Champion. Se quiser acompanhar mais conteúdo sobre Quarkus, Java e o que rola no ecossistema, me encontra aqui:

Java 26: o que muda quando você altera um campo final com reflection (JEP 500)

Luis Fabrício De Llamas — Wed, 25 Mar 2026 00:16:52 +0000

Outro dia eu estava preparando material para o DevConverge Buenos Aires, que acontece dia 11 de abril, e resolvi montar um exemplo rápido sobre uma das mudanças do Java 26 que eu acho que vai pegar muita gente de surpresa.

Não é HTTP/3. Não é o G1 mais rápido. É algo que parece simples, mas mexe com a fundação de como a gente escreve Java há anos: o JEP 500, chamado "Prepare to Make Final Mean Final", que começa a emitir warnings quando alguém muta um campo final usando reflection.

E sim, eu sei. Você provavelmente já fez isso. Eu também já fiz.

O que é o JEP 500 do Java 26?

O JEP 500 é uma mudança no Java 26 que emite um aviso em tempo de execução sempre que um campo declarado como final é alterado via deep reflection. Essa alteração faz parte da iniciativa "Integrity by Default" do OpenJDK, que pretende garantir que o modificador final seja respeitado de verdade pela JVM.

No Java 26, o comportamento padrão é emitir um warning. Em uma versão futura do JDK, esse warning será substituído por uma IllegalAccessException, bloqueando a mutação de campos final por padrão.

Por que era possível alterar campos final com reflection em Java?

Quando você declara um campo como final em Java, a ideia é clara: esse valor não muda depois que o objeto é construído. É um contrato. O compilador confia nisso.

Mas desde o JDK 5, a API de reflection permite quebrar essa promessa. Chamando setAccessible(true) e depois Field.set(...), o campo final era alterado sem nenhum aviso.

Isso nasceu para suportar serialização. A JVM precisava reconstruir objetos a partir de streams, inclusive com campos final, e não tinha outro jeito. Com o tempo, frameworks de injeção de dependência, ORMs como Hibernate, libs de mocking como Mockito e ferramentas de teste adotaram o mesmo truque. A brecha virou padrão de mercado.

O resultado? O modificador final nunca significou imutabilidade real na JVM. Até o Java 26.

Como o warning do JEP 500 aparece na prática?

Quando um campo final é mutado via reflection no Java 26, o runtime emite uma mensagem como esta:

WARNING: final field apiKey in class PaymentGatewayConfig has been mutated
reflectively by class ConfigOverrideTest in module ALL-UNNAMED.
WARNING: Use --enable-final-field-mutation=ALL-UNNAMED to avoid a warning
WARNING: Mutating final fields will be blocked in a future release unless
final field mutation is enabled

O código continua rodando. Mas o recado é claro: essa prática tem data de validade.

Exemplo prático: configuração de gateway de pagamento

Para não ficar abstrato, pensa num cenário que todo dev backend já viu. Uma classe de configuração de gateway de pagamento com campos final:

public class PaymentGatewayConfig {

    private final String apiKey;
    private final String merchantId;
    private final String environment;

    public PaymentGatewayConfig(String apiKey, String merchantId, String environment) {
        this.apiKey = apiKey;
        this.merchantId = merchantId;
        this.environment = environment;
    }

    public String apiKey() { return apiKey; }
    public String merchantId() { return merchantId; }
    public String environment() { return environment; }
}

Esses campos são final por uma razão. Depois que o gateway é configurado, ninguém deveria conseguir trocar a apiKey em runtime. Não é só boa prática, é integridade de negócio.

Agora imagina um teste, ou pior, uma lib, que faz isso nos bastidores:

PaymentGatewayConfig config = new PaymentGatewayConfig(
    "sk_live_abc123", "merchant_456", "production"
);

Field apiKeyField = PaymentGatewayConfig.class.getDeclaredField("apiKey");
apiKeyField.setAccessible(true);
apiKeyField.set(config, "sk_test_override");

System.out.println(config.apiKey()); // sk_test_override

Até o Java 25, isso passava sem nenhum sinal. No Java 26, o warning aparece. E ele está te dizendo: arruma isso enquanto dá tempo.

Quais são os modos de controle do JEP 500?

O JEP 500 introduz a flag de linha de comando --illegal-final-field-mutation com três comportamentos possíveis:

O modo warn é o padrão no Java 26. O campo final é mutado normalmente, mas o runtime emite o aviso na primeira ocorrência.

O modo debug funciona igual ao warn, mas inclui a stack trace completa. Se você tem um projeto grande com dezenas de dependências, esse é o modo que vai te mostrar de onde vem cada mutação.

O modo deny lança IllegalAccessException direto. Esse será o comportamento padrão em uma versão futura do JDK.

Se você quer se antecipar de verdade, roda seus testes assim:

java --illegal-final-field-mutation=deny -jar minha-app.jar

Se quebrar, você acaba de encontrar exatamente o que precisa corrigir.

Como permitir mutação de campos final em módulos específicos?

Nem toda dependência pode ser atualizada amanhã. O JEP 500 prevê isso e oferece um escape cirúrgico por módulo com a flag --enable-final-field-mutation:

java --enable-final-field-mutation=com.minha.lib.legada -jar minha-app.jar

Isso permite rodar com deny no geral e abrir exceção só para os módulos que realmente precisam. Para código em classpath, o famoso ALL-UNNAMED:

java --enable-final-field-mutation=ALL-UNNAMED -jar minha-app.jar

Não é um "libera tudo". É um "eu sei o que estou fazendo aqui, e documentei o motivo".

Como auditar mutações de campos final com JDK Flight Recorder?

Se você quer uma visão mais ampla do que está acontecendo em produção ou staging, o JEP 500 integra com o JDK Flight Recorder (JFR) através do evento jdk.FinalFieldMutation:

java -XX:StartFlightRecording:filename=recording.jfr -jar minha-app.jar

Depois:

jfr print --events jdk.FinalFieldMutation recording.jfr

Isso mostra cada campo final que foi mutado, por qual classe, em qual módulo. Em um sistema com muitas dependências, essa é a forma mais honesta de fazer o levantamento sem ficar adivinhando.

Quais frameworks e bibliotecas Java são afetados pelo JEP 500?

A mutação de campos final via reflection não é exclusiva de testes. Diversos tipos de bibliotecas e frameworks Java usam essa técnica: frameworks de ORM como Hibernate, bibliotecas de serialização como Jackson em certos cenários, ferramentas de mocking como Mockito e frameworks de injeção de dependência.

O escopo costuma ser maior do que a gente imagina. A recomendação é rodar os testes com --illegal-final-field-mutation=debug para descobrir todas as ocorrências com stack traces completas.

Qual é a melhor estratégia para se preparar para o JEP 500?

Ignorar os warnings porque "ainda funciona" não é estratégia. O Java segue sempre o mesmo caminho: warning primeiro, exception depois. Foi assim com --add-opens, foi assim com acesso a internals. A janela de preparação é agora.

Mas também não faz sentido ligar deny em produção amanhã cedo. Começa pelo CI. Roda a suite de testes com --illegal-final-field-mutation=debug, olha as stack traces, classifica o que é código seu e o que é dependência. Atualiza o que dá pra atualizar. Documenta o que precisa do escape. Depois avança para staging, e só então para produção.

Grava uma sessão com JFR em staging para pegar mutações que só aparecem em fluxos reais de aplicação, não cobertos por testes unitários. Depois sobe o CI com deny ativado para garantir que nenhuma regressão passe despercebida.

Por que isso importa agora

Esse é o tipo de mudança que não aparece no radar de quem olha só release notes por cima. Mas pra quem mantém sistemas em produção, é uma das mais relevantes do Java 26.

Inclusive, é exatamente esse tipo de conversa que queremos trazer no [DevConverge Buenos Aires], dia 11 de abril. A proposta é conectar devs de toda a América Latina pra falar sobre o que realmente muda no dia a dia: Java, IA, DevOps, automação. Se você constrói software e está por Buenos Aires, chega junto.

Voltando ao JEP 500: o valor real não está no warning. Está em usar essa janela de preparação para auditar o que roda no seu projeto antes que o comportamento padrão mude.

Em um sistema como gateway de pagamento, plataforma de e-commerce, serviço financeiro ou qualquer backend onde integridade de configuração importa, essa mudança é relevante. Não quando o deny virar padrão. Agora.

Perguntas frequentes sobre o JEP 500 e campos final no Java 26

O JEP 500 já bloqueia a mutação de campos final no Java 26?
Não. No Java 26, o comportamento padrão é apenas emitir um warning. O bloqueio com IllegalAccessException será o padrão em uma versão futura do JDK.

Qual a diferença entre --illegal-final-field-mutation e --enable-final-field-mutation?
A flag --illegal-final-field-mutation controla o comportamento global (warn, debug ou deny). A flag --enable-final-field-mutation permite habilitar a mutação seletivamente para módulos específicos, funcionando como um escape controlado.

Records são afetados pelo JEP 500?
Não. Os campos implicitamente declarados em records já não permitiam mutação via deep reflection antes do Java 26. O JEP 500 alinha o comportamento de classes normais com o que records já faziam.

Como saber se minhas dependências mutam campos final?
Rode sua aplicação ou testes com --illegal-final-field-mutation=debug para ver warnings com stack trace completa. Para produção, use o JDK Flight Recorder com o evento jdk.FinalFieldMutation.

Preciso atualizar meu código agora?
Sim, é recomendável começar a auditoria agora. A transição de warning para exception seguirá o mesmo padrão de outras mudanças de integridade do JDK. Quanto antes você identificar as ocorrências, mais tranquila será a migração.

Eu sou o Luis De Llamas, Developer Advocate na act digital, Oracle ACE e IBM Champion. Se quiser acompanhar mais conteúdo sobre Quarkus, Java e o que rola no ecossistema, me encontra aqui:

Nos vemos!

Testei o HttpClient do Java 26 com HTTP/3 em um agregador de viagens. E isso é o que realmente importa

Luis Fabrício De Llamas — Mon, 23 Mar 2026 00:57:19 +0000

Testei o HttpClient do Java 26 com HTTP/3 em um agregador de viagens. E isso é o que realmente importa

Se você trabalha com sistemas backend que dependem de APIs externas, já sabe que o problema nem sempre está no seu código.

Às vezes, o gargalo real está no caminho entre o seu serviço e os sistemas de terceiros.

É por isso que o suporte a HTTP/3 no HttpClient do Java 26 é realmente interessante. Não porque “suporte a novo protocolo” fica bonito em release note, mas porque isso pode mudar o comportamento de aplicações Java que dependem de múltiplos serviços remotos sob pressão de latência.

Para não ficar só na teoria, eu montei uma aplicação demo com um cenário de agregador de viagens. O projeto está aqui:

https://github.com/dellamas/java26-http3-travel-aggregator-demo

A ideia foi simular um backend que consulta múltiplos fornecedores em paralelo para consolidar opções de hospedagem, algo bem mais próximo do mundo real do que um exemplo genérico de chamada HTTP isolada.

Depois de analisar as mudanças do HttpClient no Java 26, o suporte a HTTP/3 e montar esse exemplo, a conclusão mais importante foi simples:

HTTP/3 importa, mas o protocolo em si não é a história completa. O que realmente importa é como você decide usar isso.

Um contexto mais realista

Imagine uma API de agregação de viagens. O cliente faz uma busca por hotéis em Gramado ( saudades, por sinal!), e o seu serviço precisa consultar múltiplos provedores antes de devolver a resposta final.

Uma única requisição pode disparar chamadas para:

uma API de fornecedores de hospedagem
um serviço de precificação
uma API de avaliações
um serviço de cupons ou fidelidade

Esse tipo de fluxo é comum em marketplaces, plataformas de reserva, integrações financeiras e sistemas logísticos.

Nesse cenário, pequenos atrasos se acumulam rápido. Uma única chamada externa mais lenta pode puxar para baixo o tempo total de resposta. E quando a rede está instável, comportamento de fallback e recuperação passam a importar ainda mais.

É aqui que HTTP/3 começa a ficar interessante.

O que mudou no Java 26

O Java 26 adicionou suporte a HTTP/3 no java.net.http.HttpClient.

Isso significa que agora você pode preferir explicitamente HTTP_3 ao construir um client ou uma request.

Um exemplo simples fica assim:

HttpClient client = HttpClient.newBuilder()
        .version(HttpClient.Version.HTTP_3)
        .build();

HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create("https://api.parceiro-viagens.com/hoteis/busca"))
        .header("Accept", "application/json")
        .POST(HttpRequest.BodyPublishers.ofString("""
                {
                  \"destino\": \"Gramado\",
                  \"checkIn\": \"2026-04-10\",
                  \"checkOut\": \"2026-04-13\",
                  \"hospedes\": 2
                }
                """))
        .build();

HttpResponse<String> response =
        client.send(request, HttpResponse.BodyHandlers.ofString());

System.out.println(response.statusCode());
System.out.println(response.version());

Essa é a parte fácil.

A parte mais importante é decidir como sua aplicação deve se comportar quando o serviço remoto não suporta HTTP/3, ou quando suporta, mas nem sempre essa é a melhor escolha.

Um exemplo com código mais próximo de aplicação real

Na demo que eu subi no GitHub, a aplicação usa HttpClient, virtual threads, timeouts explícitos e um fan out simples para múltiplos fornecedores.

O coração do exemplo é este:

HttpClient client = HttpClient.newBuilder()
        .version(HttpClient.Version.HTTP_2)
        .connectTimeout(Duration.ofSeconds(2))
        .build();

List<URI> fornecedores = List.of(
        URI.create("https://api.fornecedor-a.com/hoteis/busca"),
        URI.create("https://api.fornecedor-b.com/hoteis/busca"),
        URI.create("https://api.fornecedor-c.com/hoteis/busca")
);

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<Future<String>> futures = fornecedores.stream()
            .map(uri -> executor.submit(() -> {
                HttpRequest request = HttpRequest.newBuilder()
                        .uri(uri)
                        .timeout(Duration.ofSeconds(3))
                        .header("Content-Type", "application/json")
                        .POST(HttpRequest.BodyPublishers.ofString(payload))
                        .build();

                HttpResponse<String> response =
                        client.send(request, HttpResponse.BodyHandlers.ofString());

                if (response.statusCode() >= 400) {
                    throw new IllegalStateException("Fornecedor falhou: " + uri);
                }

                return response.body();
            }))
            .toList();

    return futures.stream().map(Future::get).toList();
}

Na demo, eu deixei HTTP_2 por padrão para manter o projeto estável e executável em ambiente comum. Mas o ponto do artigo continua valendo: quando você estiver em Java 26 com suporte a HTTP/3 disponível, a decisão relevante não é só trocar a versão do protocolo. É medir o impacto em um cenário real.

Por que HTTP/3 interessa para backend

Do ponto de vista de funcionalidade, HTTP/3 não parece revolucionário quando comparado com HTTP/2.

A grande diferença está por baixo.

HTTP/2 roda sobre TCP.
HTTP/3 roda sobre QUIC, que usa UDP.

Essa mudança afeta comportamento de conexão, recuperação e performance, principalmente em cenários com perda de pacote, instabilidade de rede ou reconexões frequentes.

Na prática, isso torna HTTP/3 especialmente interessante para sistemas que:

dependem de várias APIs externas
se preocupam com latência de cauda
rodam em ambientes distribuídos
precisam lidar bem com redes imperfeitas
fazem fan out para múltiplos parceiros

Toda aplicação Java vai ficar mais rápida só porque você definiu HTTP_3?

Não.

E é justamente por isso que esse tema merece uma conversa mais honesta.

A decisão real não é “usar HTTP/3 ou não”

A decisão real é sobre estratégia.

Estratégia 1: preferir HTTP/3 primeiro

Se você acredita que o serviço remoto já suporta HTTP/3 e quer aproveitar isso quando estiver disponível, esse é o caminho mais direto.

HttpClient client = HttpClient.newBuilder()
        .version(HttpClient.Version.HTTP_3)
        .build();

Isso faz sentido quando existe confiança no ecossistema do parceiro e você quer testar um caminho mais moderno logo de saída.

Estratégia 2: usar HTTP/3 só em requisições específicas

Nem toda integração merece o mesmo tratamento.

Talvez a API de preços seja uma boa candidata para teste com HTTP/3, enquanto um provedor legado de reservas ainda se comporta melhor com uma negociação mais conservadora.

HttpClient client = HttpClient.newBuilder().build();

HttpRequest requestBusca = HttpRequest.newBuilder()
        .uri(URI.create("https://api.parceiro-viagens.com/hoteis/busca"))
        .version(HttpClient.Version.HTTP_3)
        .GET()
        .build();

Essa é a abordagem que eu mais gosto para produção, porque é incremental e mais fácil de observar.

Estratégia 3: tratar fallback como parte do desenho

Só porque Java 26 suporta HTTP/3 não significa que seu modelo mental deva ser “agora tudo é HTTP/3”.

Em um agregador de viagens, fallback elegante importa mais do que entusiasmo com protocolo.

Seu trabalho não é defender uma posição ideológica sobre transporte.
Seu trabalho é devolver uma boa resposta de forma consistente.

Se um fornecedor não suporta bem HTTP/3, ou se a negociação cair para HTTP/2, isso não é fracasso. Isso é comportamento normal.

A pergunta útil é esta:

essa estratégia de client reduz latência e mantém previsibilidade sob tráfego real?

É isso que interessa.

O que eu não faria

“HTTP/3 é automaticamente mais rápido”

Não necessariamente.

Se o seu parceiro está lento por causa de contenção de banco, HTTP/3 não vai te salvar.

“Agora eu devo forçar HTTP/3 em tudo”

Também não.

Um backend com várias integrações quase sempre vive num ecossistema heterogêneo.
Forçar escolha de protocolo sem medir antes costuma ser pior do que adotar com critério.

“Isso é só detalhe de client”

Não é.

Em sistemas distribuídos, comportamento de transporte também é comportamento da aplicação.

O que eu testaria de verdade

Se eu estivesse avaliando adoção de HTTP/3 em backend Java, eu testaria assim:

escolher uma integração com sensibilidade real a latência
comparar percentis de resposta, não só média
observar o comportamento de fallback
monitorar handshake e reaproveitamento de conexão
comparar taxa de erro em condição degradada
evitar tirar conclusão com benchmark local

Minha conclusão

O suporte a HTTP/3 no HttpClient do Java 26 não é só uma feature para preencher release note.

Ele é útil porque dá aos desenvolvedores Java uma forma melhor de lidar com a web moderna usando a biblioteca padrão.

Mas o valor real não está em escrever isto:

.version(HttpClient.Version.HTTP_3)

O valor real está em saber onde essa decisão ajuda, onde fallback precisa continuar fazendo parte do desenho, e como a escolha do protocolo afeta o comportamento da aplicação em sistemas distribuídos.

Em um sistema como agregador de viagens, plataforma de reservas, hub logístico ou camada de integração financeira, é aí que essa feature começa a fazer sentido.

Não no anúncio.
Na arquitetura.

Eu sou o Luis De Llamas, Developer Advocate na act digital, Oracle ACE e IBM Champion. Se quiser acompanhar mais conteúdo sobre Quarkus, Java e o que rola no ecossistema, me encontra aqui:

Nos vemos!

Quarkus Reactive Routes na prática: triagem de incidentes com fluxo reativo de verdade

Luis Fabrício De Llamas — Sat, 21 Mar 2026 01:13:27 +0000

Quarkus Reactive Routes na prática: triagem de incidentes com fluxo reativo de verdade

Se você já trabalhou com observabilidade, suporte ou operação, sabe que incidente costuma começar com pressão, sinais espalhados e pouca clareza sobre o que precisa entrar primeiro na fila. Nesse tipo de cenário, não basta expor um endpoint. O desafio é organizar o fluxo de forma simples, legível e compatível com uma aplicação que precisa reagir rápido.

Neste artigo eu vou mostrar um exemplo de triagem de incidentes com Quarkus Reactive Routes em um contexto mais próximo de uma operação real. A proposta é montar uma API pequena, com fila priorizada, resumo operacional e stream SSE para acompanhamento ao vivo.

Vale registrar um detalhe histórico. A base dessa linha de funcionalidade entrou no Quarkus no trabalho do Martin Kouba, no commit "Add Vertx web extension" do repositório quarkusio/quarkus. Isso ajuda a entender por que o recurso tem uma integração tão direta com o ecossistema do Vert.x.

O que vamos construir

Uma API de triagem operacional com quatro rotas principais:

POST /incidents para registrar um incidente
GET /incidents/priority-board para listar a fila priorizada
GET /incidents/summary para consolidar o estado operacional
GET /incidents/live para acompanhar snapshots em SSE

Estrutura do projeto:

src/main/java/br/com/luisf/fabricio/demos/reactive/routes/incident/
├── api/
│ ├── CreateIncidentRequest.java
│ ├── CreatedIncidentEnvelope.java
│ ├── IncidentLiveSignal.java
│ ├── IncidentResponse.java
│ ├── IncidentRoutes.java
│ ├── IncidentSummaryResponse.java
│ └── PriorityBoardResponse.java
├── domain/
│ ├── Incident.java
│ ├── IncidentStatus.java
│ └── Severity.java
├── health/
│ └── IncidentDispatchHealthCheck.java
└── service/
├── IncidentDispatchService.java
└── IncidentMapper.java

Criando a base do projeto

A stack ficou enxuta para destacar o Reactive Routes sem espalhar a atenção em infraestrutura paralela:

quarkus-reactive-routes
quarkus-rest-jackson
quarkus-smallrye-openapi
quarkus-swagger-ui
quarkus-smallrye-health
quarkus-hibernate-validator

O domínio e os contratos

O domínio foi mantido simples. Incident.java representa o incidente, Severity.java define a prioridade operacional e IncidentStatus.java mantém o estado mínimo do fluxo.

Severity.java ficou assim:

public enum Severity {
    LOW(1),
    MEDIUM(2),
    HIGH(3),
    CRITICAL(4);

    private final int priority;

    Severity(int priority) {
        this.priority = priority;
    }

    public int priority() {
        return priority;
    }
}

No pacote api/, cada classe cumpre um papel claro:

CreateIncidentRequest.java define o payload de entrada
IncidentResponse.java representa o incidente devolvido ao cliente
CreatedIncidentEnvelope.java adiciona a mensagem de confirmação
PriorityBoardResponse.java devolve a fila ordenada
IncidentSummaryResponse.java consolida o resumo operacional
IncidentLiveSignal.java modela cada snapshot emitido pelo SSE

Essa separação ajuda bastante porque o contrato da API fica explícito logo na leitura inicial do projeto.

O coração da lógica: IncidentDispatchService.java

Esse é o arquivo principal do projeto. É nele que entram armazenamento em memória, ordenação da fila, criação de incidentes, geração do resumo e emissão dos snapshots ao vivo.

A regra de priorização ficou assim:

private static final Comparator<Incident> INCIDENT_PRIORITY = Comparator
        .comparingInt((Incident incident) -> incident.severity().priority())
        .reversed()
        .thenComparing(Incident::openedAt);

Severidade mais alta sobe na fila e, entre incidentes do mesmo nível, o mais antigo vem primeiro.

A criação do incidente também ficou toda visível no serviço:

public Uni<IncidentResponse> create(CreateIncidentRequest request) {
    OffsetDateTime now = OffsetDateTime.now(ZoneOffset.UTC);
    Incident incident = new Incident(
            "INC-" + sequence.incrementAndGet(),
            request.severity(),
            request.affectedService().trim(),
            request.summary().trim(),
            request.owner().trim(),
            IncidentStatus.OPEN,
            now,
            now);
    incidents.add(incident);
    return Uni.createFrom().item(mapper.toResponse(incident));
}

E o stream SSE sai do mesmo serviço:

public Multi<IncidentLiveSignal> liveSignals() {
    return Multi.createFrom().ticks().every(Duration.ofSeconds(1))
            .onItem().transform(index -> new IncidentLiveSignal(
                    Math.toIntExact(index) + 1,
                    "incident-dispatch",
                    OffsetDateTime.now(ZoneOffset.UTC),
                    summarySnapshot(),
                    priorityBoardSnapshot().queue().stream().findFirst().orElse(null)))
            .select().first(5);
}

Mapeamento e borda HTTP

IncidentMapper.java faz a conversão entre domínio e resposta HTTP. Pode parecer detalhe, mas essa separação evita misturar regra de negócio com montagem de payload.

IncidentRoutes.java concentra as quatro rotas da aplicação. A criação do incidente ficou assim:

@Route(path = "", methods = Route.HttpMethod.POST, consumes = "application/json")
public Uni<CreatedIncidentEnvelope> create(HttpServerResponse response, @Body @Valid CreateIncidentRequest request) {
    response.setStatusCode(201);
    return service.create(request)
            .onItem().transform(incident -> new CreatedIncidentEnvelope(
                    "Incident registered and queued for reactive triage.", incident));
}

A fila priorizada e o resumo retornam Uni:

@Route(path = "priority-board", methods = Route.HttpMethod.GET)
public Uni<PriorityBoardResponse> priorityBoard() {
    return service.priorityBoard();
}

@Route(path = "summary", methods = Route.HttpMethod.GET)
public Uni<IncidentSummaryResponse> summary() {
    return service.summary();
}

E o acompanhamento ao vivo usa SSE:

@Route(path = "live", methods = Route.HttpMethod.GET, produces = "text/event-stream")
public Multi<String> live() {
    return service.liveSignals().onItem().transform(this::toSsePayload);
}

Health check e configuração

IncidentDispatchHealthCheck.java responde a uma pergunta simples: o serviço está de pé?

O application.properties também ficou enxuto:

quarkus.http.port=8080
quarkus.swagger-ui.always-include=true
quarkus.smallrye-openapi.info-title=Reactive Incident Dispatch API
quarkus.smallrye-openapi.info-version=1.0.0
quarkus.smallrye-openapi.info-description=API reativa para despacho e triagem de incidentes operacionais.
quarkus.http.enable-compression=true

Como rodar

git clone https://github.com/dellamas/quarkus-reactive-routes-incident-dispatch-api
cd quarkus-reactive-routes-incident-dispatch-api
mvn quarkus:dev

Criando um incidente:

curl -X POST http://localhost:8080/incidents \
  -H "Content-Type: application/json" \
  -d '{
    "severity": "HIGH",
    "affectedService": "telemetry-gateway",
    "summary": "Atraso na entrega de métricas de disponibilidade",
    "owner": "observability-core"
  }'

Consultando a fila:

curl http://localhost:8080/incidents/priority-board

Consultando o resumo:

curl http://localhost:8080/incidents/summary

Abrindo o stream:

curl http://localhost:8080/incidents/live

O que este projeto mostra na prática

O Quarkus Reactive Routes funciona muito bem quando você quer expor rotas curtas, fluxo reativo explícito e um contrato HTTP fácil de acompanhar. Neste exemplo, isso aparece na combinação entre criação de incidente, fila priorizada, resumo consolidado e stream SSE.

Mostrar as classes do fluxo também ajuda bastante. Você entende onde está o contrato, onde está a regra, onde está o mapeamento e onde está a borda HTTP.

O código completo está no GitHub:

https://github.com/dellamas/quarkus-reactive-routes-incident-dispatch-api

Se quiser acompanhar mais conteúdo meu, me segue no LinkedIn:

https://www.linkedin.com/in/luisfabriciodellamas/

E no Insta:

https://instagram.com/luisdellamas

SmallRye Fault Tolerance na prática: retry, fallback e circuit breaker em um gateway Pix com Quarkus

Luis Fabrício De Llamas — Mon, 16 Mar 2026 15:12:40 +0000

Neste artigo mostro como usar SmallRye Fault Tolerance com Quarkus para proteger um gateway Pix com @Retry, @Timeout, @CircuitBreaker e @Fallback. O cenário simula uma fintech que precisa de resiliência real quando o provedor de autorização fica instável.

O cenário que eu montei

A aplicação simula um gateway Pix de fintech recebendo pedidos de cobrança e chamando um provedor externo de autorização. Quando esse provedor fica instável, a API não pode simplesmente responder erro para tudo e deixar o time operacional apagar incêndio no braço.

Para esse lab, o fluxo ficou assim:

cobrança comum tenta novamente e segue o jogo
cobrança mais alta não insiste para sempre
quando o risco operacional aumenta, a resposta volta como análise manual

Foi aí que quarkus-smallrye-fault-tolerance fez sentido de verdade.

Estrutura do projeto

.
├── README.md
├── ARTICLE.md
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── dev
│   │   │       └── dailylab
│   │   │           └── payments
│   │   │               ├── PixChargeRequest.java
│   │   │               ├── PixChargeResource.java
│   │   │               ├── PixChargeResult.java
│   │   │               ├── PixChargeService.java
│   │   │               └── PixGatewayClient.java
│   │   └── resources
│   │       └── application.properties
│   └── test
│       └── java
│           └── dev
│               └── dailylab
│                   └── payments
│                       └── PixChargeResourceTest.java
└── mvnw

Onde a extensão entrou de verdade

O coração do lab está no serviço. A chamada externa foi protegida com retry, timeout, circuit breaker e fallback no mesmo método.

@Retry(maxRetries = 2, delay = 200, delayUnit = ChronoUnit.MILLIS)
@Timeout(value = 400, unit = ChronoUnit.MILLIS)
@CircuitBreaker(requestVolumeThreshold = 4, failureRatio = 0.75, delay = 2, delayUnit = ChronoUnit.SECONDS)
@Fallback(fallbackMethod = "reserveForManualReview")
public PixChargeResult process(PixChargeRequest request) {
    int attempt = gatewayClient.nextAttempt();
    if (request.amount().compareTo(new BigDecimal("1500.00")) > 0) {
        throw new IllegalStateException("provider timeout on high-value pix charge");
    }
    if (attempt < 3) {
        throw new IllegalStateException("temporary provider instability on attempt " + attempt);
    }
    return new PixChargeResult(
            "APPROVED",
            "primary-pix-provider",
            request.amount(),
            "Charge approved after retry strategy stabilized the provider call",
            request.correlationId());
}

O que eu gosto aqui é que a regra fica visível. Não tem controller fazendo malabarismo, nem exception espalhada em três camadas diferentes. A decisão operacional está no ponto em que a falha realmente importa.

O endpoint HTTP ficou enxuto:

@Path("/pix-charges")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class PixChargeResource {

    private final PixChargeService service;

    public PixChargeResource(PixChargeService service) {
        this.service = service;
    }

    @POST
    public PixChargeResult create(PixChargeRequest request) {
        return service.process(request);
    }
}

Configuração usada

A configuração ficou pequena porque o objetivo era mostrar a extensão resolvendo um caso concreto.

quarkus.swagger-ui.always-include=true
quarkus.smallrye-openapi.info-title=Lab SmallRye Fault Tolerance
quarkus.smallrye-openapi.info-version=1.0.0
quarkus.smallrye-openapi.info-description=API de fallback para cobrancas Pix em um contexto de antifraude e estabilidade de gateway.

Como rodar e testar

Subindo localmente:

./mvnw quarkus:dev

Cobrança que passa depois do retry:

curl -X POST http://localhost:8080/pix-charges \
  -H 'Content-Type: application/json' \
  -d '{
    "customerId": "cust-01",
    "amount": 1200.00,
    "correlationId": "pix-001"
  }'

Cobrança que desvia para análise manual:

curl -X POST http://localhost:8080/pix-charges \
  -H 'Content-Type: application/json' \
  -d '{
    "customerId": "cust-02",
    "amount": 2500.00,
    "correlationId": "pix-002"
  }'

Swagger:

http://localhost:8080/q/swagger-ui

O que eu tirei desse lab

Essa extensão ganha muito quando o exemplo deixa de ser acadêmico. No caso da cobrança Pix, retry e fallback não são enfeite: eles viram uma decisão de operação. Cobrança pequena pode insistir um pouco. Cobrança maior precisa preservar o sistema e cair para outro fluxo.

Também ficou claro que esse tipo de lab funciona melhor quando o código é curto, o cenário é específico e o teste cobre a resposta final. A leitura fica muito mais honesta.

Link pro GitHub

https://github.com/dellamas/quarkus-smallrye-fault-tolerance

Gostou e quer ver mais conteúdos como este? Então deixa uma ⭐ no repositório.

No LinkedIn eu sempre posto sobre eventos, comunidade Java e Quarkus:

💼 LinkedIn

E o artigo deste projeto está no dev.to:

✍️ dev.to

Quarkus Scheduler na prática

Luis Fabrício De Llamas — Sun, 15 Mar 2026 17:11:32 +0000

Se você já trabalhou com sistemas financeiros, sabe que uma das tarefas mais comuns é lidar com tarefas agendadas: verificar vencimentos, processar cobranças, gerar relatórios diários. No mundo Spring Boot, muita gente recorre ao @Scheduled. No Quarkus, temos o Quarkus Scheduler — e ele é bem direto ao ponto.

Nesse post vou mostrar como usar o Scheduler num contexto real de fintech, sem aquele exemplo de "contador que incrementa a cada 10 segundos" que todo tutorial usa. Bora?

O que vamos construir

Uma API de cobranças com três jobs agendados:

A cada 30 segundos: verifica vencimentos e atualiza status
Todo dia às 8h: inicia o processamento das cobranças pendentes
Todo dia às 18h: gera um relatório com totais

Estrutura do projeto:

src/main/java/dev/dellamas/fintech/
├── model/
│   └── Cobranca.java
├── service/
│   └── CobrancaService.java
├── scheduler/
│   └── CobrancaScheduler.java
└── resource/
    └── CobrancaResource.java

Criando o projeto

mvn io.quarkus.platform:quarkus-maven-plugin:3.18.4:create \
  -DprojectGroupId=dev.dellamas \
  -DprojectArtifactId=quarkus-scheduler-fintech \
  -Dextensions="rest,scheduler,rest-jackson" \
  -DnoCode

O modelo: Cobranca.java

Vamos começar pelo modelo. Nada sofisticado aqui — uma cobrança com id, cliente, valor, vencimento e status. Mas já pensou quantas vezes você viu um sistema que não tem nem isso bem definido?

package dev.dellamas.fintech.model;

import java.math.BigDecimal;
import java.time.LocalDate;

public class Cobranca {

    private String id;
    private String cliente;
    private BigDecimal valor;
    private LocalDate vencimento;
    private StatusCobranca status;

    public enum StatusCobranca {
        PENDENTE, PROCESSANDO, PAGA, VENCIDA
    }

    public Cobranca(String id, String cliente, BigDecimal valor, LocalDate vencimento) {
        this.id = id;
        this.cliente = cliente;
        this.valor = valor;
        this.vencimento = vencimento;
        this.status = StatusCobranca.PENDENTE;
    }

    public String getId() { return id; }
    public String getCliente() { return cliente; }
    public BigDecimal getValor() { return valor; }
    public LocalDate getVencimento() { return vencimento; }
    public StatusCobranca getStatus() { return status; }
    public void setStatus(StatusCobranca status) { this.status = status; }
}

Sem persistência por enquanto — o foco aqui é no Scheduler. Num projeto real, isso viraria uma entidade Panache sem dor.

O serviço: CobrancaService.java

Esse é o coração da lógica. Ele mantém as cobranças em memória e expõe os métodos que os jobs vão chamar. Perceba o ConcurrentHashMap — os jobs rodam em threads separadas, então se você não pensar em concorrência aqui, vai ter problema cedo ou tarde.

package dev.dellamas.fintech.service;

import dev.dellamas.fintech.model.Cobranca;
import dev.dellamas.fintech.model.Cobranca.StatusCobranca;
import jakarta.enterprise.context.ApplicationScoped;

import java.math.BigDecimal;
import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.stream.Collectors;

@ApplicationScoped
public class CobrancaService {

    private final Map<String, Cobranca> cobrancas = new ConcurrentHashMap<>();

    public CobrancaService() {
        cobrancas.put("C001", new Cobranca("C001", "Empresa Alpha",
                new BigDecimal("1500.00"), LocalDate.now().minusDays(1)));
        cobrancas.put("C002", new Cobranca("C002", "Startup Beta",
                new BigDecimal("890.50"), LocalDate.now()));
        cobrancas.put("C003", new Cobranca("C003", "Loja Gamma",
                new BigDecimal("3200.00"), LocalDate.now().plusDays(5)));
        cobrancas.put("C004", new Cobranca("C004", "Consultoria Delta",
                new BigDecimal("650.00"), LocalDate.now().minusDays(3)));
    }

    public List<Cobranca> listarTodas() {
        return new ArrayList<>(cobrancas.values());
    }

    public List<Cobranca> listarVencidas() {
        return cobrancas.values().stream()
                .filter(c -> c.getVencimento().isBefore(LocalDate.now())
                        && c.getStatus() == StatusCobranca.PENDENTE)
                .collect(Collectors.toList());
    }

    public List<Cobranca> listarPendentes() {
        return cobrancas.values().stream()
                .filter(c -> c.getStatus() == StatusCobranca.PENDENTE)
                .collect(Collectors.toList());
    }

    public int marcarVencidasComoVencidas() {
        List<Cobranca> vencidas = listarVencidas();
        vencidas.forEach(c -> c.setStatus(StatusCobranca.VENCIDA));
        return vencidas.size();
    }

    public int processarPendentes() {
        List<Cobranca> pendentes = listarPendentes();
        pendentes.forEach(c -> c.setStatus(StatusCobranca.PROCESSANDO));
        return pendentes.size();
    }

    public BigDecimal totalVencido() {
        return cobrancas.values().stream()
                .filter(c -> c.getStatus() == StatusCobranca.VENCIDA)
                .map(Cobranca::getValor)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
}

Os jobs agendados: CobrancaScheduler.java

Aqui é onde o Quarkus Scheduler entra. A anotação @Scheduled aceita dois formatos: intervalo fixo com every e expressão cron com cron. Qual usar? Depende. Pra verificações frequentes, every resolve. Pra tarefas que precisam rodar em horário específico, cron é o caminho.

package dev.dellamas.fintech.scheduler;

import dev.dellamas.fintech.service.CobrancaService;
import io.quarkus.scheduler.Scheduled;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;
import org.jboss.logging.Logger;

@ApplicationScoped
public class CobrancaScheduler {

    private static final Logger LOG = Logger.getLogger(CobrancaScheduler.class);

    @Inject
    CobrancaService cobrancaService;

    @Scheduled(every = "30s")
    void verificarVencimentos() {
        int total = cobrancaService.marcarVencidasComoVencidas();
        if (total > 0) {
            LOG.infof("Vencimentos processados: %d cobrança(s) marcadas como vencidas", total);
        }
    }

    @Scheduled(cron = "0 0 8 * * ?")
    void processarCobrancasDiarias() {
        int total = cobrancaService.processarPendentes();
        LOG.infof("Processamento diário iniciado: %d cobrança(s) em processamento", total);
    }

    @Scheduled(cron = "0 0 18 * * ?")
    void gerarRelatorioDiario() {
        var vencidas = cobrancaService.listarVencidas().size();
        var totalVencido = cobrancaService.totalVencido();
        LOG.infof("Relatório diário — Cobranças vencidas: %d | Total em aberto: R$ %s",
                vencidas, totalVencido);
    }
}

O formato de cron padrão no Quarkus é o do Quartz (6 campos, com segundos). Se você prefere o formato Unix de 5 campos, troca no application.properties:

quarkus.scheduler.cron-type=unix

O endpoint REST: CobrancaResource.java

Pra fechar, precisamos expor o estado das cobranças. Afinal, de que adianta processar tudo em background se ninguém consegue consultar?

package dev.dellamas.fintech.resource;

import dev.dellamas.fintech.model.Cobranca;
import dev.dellamas.fintech.service.CobrancaService;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

import java.util.List;

@Path("/cobrancas")
@Produces(MediaType.APPLICATION_JSON)
public class CobrancaResource {

    @Inject
    CobrancaService cobrancaService;

    @GET
    public List<Cobranca> listarTodas() {
        return cobrancaService.listarTodas();
    }

    @GET
    @Path("/vencidas")
    public List<Cobranca> listarVencidas() {
        return cobrancaService.listarVencidas();
    }

    @GET
    @Path("/pendentes")
    public List<Cobranca> listarPendentes() {
        return cobrancaService.listarPendentes();
    }

    @GET
    @Path("/resumo")
    @Produces(MediaType.TEXT_PLAIN)
    public String resumo() {
        return String.format("Total vencido: R$ %s | Vencidas: %d | Pendentes: %d",
                cobrancaService.totalVencido(),
                cobrancaService.listarVencidas().size(),
                cobrancaService.listarPendentes().size());
    }
}

Configuração

application.properties:

quarkus.application.name=quarkus-scheduler-fintech
quarkus.scheduler.cron-type=quartz

Rodando

git clone https://github.com/dellamas/quarkus-scheduler-fintech
cd quarkus-scheduler-fintech
./mvnw quarkus:dev

Assim que subir, o job de verificação de vencimentos já começa a rodar a cada 30 segundos. Acompanhe no terminal e, em paralelo, teste:

curl http://localhost:8080/cobrancas
curl http://localhost:8080/cobrancas/vencidas
curl http://localhost:8080/cobrancas/resumo

Por que o Scheduler e não o Quartz?

O quarkus-scheduler é a opção leve — resolve bem pra aplicações de instância única. Precisa de clustering, com múltiplas instâncias disputando o mesmo job? Aí o quarkus-quartz faz mais sentido. Mas pra maioria dos cenários do dia a dia, o Scheduler padrão dá conta.

O código completo está no GitHub. Se fez sentido pra você, deixa uma estrela no repositório — ajuda mais do que parece.

Eu sou o Luis De Llamas, Developer Advocate na act digital, Oracle ACE e IBM Champion. Se quiser acompanhar mais conteúdo sobre Quarkus, Java e o que rola no ecossistema, me encontra aqui:

Nos vemos no próximo.

Bob - how much is your time worth?

Luis Fabrício De Llamas — Sun, 16 Nov 2025 14:30:33 +0000

Bob continues to surprise me.

Recently, I took a moment to observe how the developers I know are using AI in their daily work. It’s not that AI isn’t present. It is. But the way it’s used still feels far from being truly integrated into the development process. And this varies a lot depending on the developer’s seniority. In some cases, this difference can even affect the process of building long-term knowledge, which is a topic worthy of its own post.  But the question that stayed in my mind was another one: why aren’t we using AI in a more fluid, natural way, as part of our workflow?

Are we lacking clarity about what should be delegated? Are we lacking trust?

With that in mind, I decided to take advantage of my early access to Project Bob ( IBM ) and run a more realistic test. I listed a few tasks that I see happening all the time in daily development work, tasks that no one finds particularly difficult, but everyone knows are… exhausting. Lots of small steps, legacy dependencies, old codebases, short but vague specs, branch creation, tiny adjustments, tests, validations… that classic mix of little things that end up consuming a huge amount of time.

I picked a very concrete task: modernizing a #Java 8 application to Java 21 and replacing RestTemplate with RestClient. Nothing epic, nothing extremely complex, just something extremely common in the life of a backend Java developer. And then another question came to mind: why do tasks we understand so well still take so long?

When you look at the modernization, the value is obvious. Java 21 brings better performance, improved security, new language features, and virtual threads. The modern Spring Boot ecosystem requires Jakarta. And RestTemplate, even though it has been our companion for so many years, no longer receives improvements, while RestClient provides a much more intuitive, modern, and fluent API. It’s hard not to want something better.

The example application had the same foundation many systems still have today: Java 8, Spring Boot 2.x, RestTemplate, and javax.validation. After the modernization, it became a current and fully updated application using Java 21, Spring Boot 3.x, RestClient, Jakarta Validation, and virtual threads.

The prompt I used was:

“Update this project from Java 8 to Java 21 and replace all usages of RestTemplate with the new Spring RestClient API. Modernize the code where needed, adjust dependencies, update configuration, and ensure compatibility with Spring Boot’s latest recommended patterns. Provide the updated code examples and explain any breaking changes or required refactoring.”

And here comes the interesting part. This entire task, which normally involves understanding the context, reviewing code, updating dependencies, replacing HTTP calls, testing functionality, reviewing behaviors, fixing warnings, validating the flow, and ensuring compatibility, would easily be estimated at two days of work. I did the whole thing with Bob and, in a demo extremely similar to a real-world scenario, everything was completed in just over four minutes, as you can see in the video.

It’s hard not to stop and think: Does Bob really understand the project?

Based on what I saw, the answer is yes. He understands the context, the application’s style, the dependencies, the patterns used, and the adjustments required. And he does this in a way that doesn’t disrupt the developer, doesn’t break the flow, and doesn’t require you to adapt too much. He simply works with you.

And there’s more. IBM has already reported real productivity gains close to forty-five percent in teams that tested Bob. It helps understand legacy code, accelerates onboarding for new developers, reduces migration effort, supports complex modernization tasks, and removes a huge amount of repetitive work from developers’ shoulders.

So the big question is: why are we still doing all of this manually? How many tasks like this are sitting in your backlog right now? What could you be delivering or learning if part of this work were delegated?

Tools like Bob weren’t created just to speed up delivery. They were created to transform the way we work, freeing time and energy for what actually helps developers evolve: creating, thinking, deciding, exploring, connecting ideas, and delivering real value.

And here’s a fun note: as I’m writing this post, Bob is currently migrating this same application to #Quarkus. So let me ask you this… how much is your time worth?

Oh, and if you enjoyed this content and want to learn more about emerging technologies, here’s an invitation!

We have a very active community where we share knowledge, answer questions, and network.

Join the Quarkus Club:

Discord: https://discord.gg/nMeSs2u4ZJ
YouTube: https://www.youtube.com/@QuarkusClub

And if you’d like to chat about Oracle, AI, or any tech topic in general, feel free to connect with me on LinkedIn:

LinkedIn: https://www.linkedin.com/in/luisfabriciodellamas/

Instrumentação com OpenTelemetry: Zero-Code, Code-Based ou Bibliotecas Instrumentadas?

Luis Fabrício De Llamas — Sat, 05 Oct 2024 01:19:40 +0000

A instrumentação é o coração da observabilidade em sistemas complexos e distribuídos, e ferramentas como o OpenTelemetry estão transformando a forma como desenvolvedores e arquitetos coletam dados de suas aplicações. Neste artigo, vamos explorar as três abordagens principais de instrumentação oferecidas pelo OpenTelemetry: instrumentação zero-code, instrumentação code-based e bibliotecas instrumentadas. Cada uma delas possui suas vantagens e desvantagens, e entender qual delas utilizar pode ser determinante para o sucesso do monitoramento do seu sistema.

Instrumentação Zero-Code: Simplicidade ou Limitação?

A instrumentação zero-code é uma proposta intrigante. O conceito é simples: sem precisar modificar o código da aplicação, você consegue coletar métricas e traços diretamente. Isso se torna possível através de agentes ou ferramentas que fazem o trabalho pesado nos bastidores, interceptando chamadas e gerando os dados de observabilidade.

Imagine que você tem um sistema legado, ou até mesmo uma aplicação moderna, e precisa urgentemente começar a monitorar seu desempenho. A zero-code permite que você faça isso rapidamente. No entanto, há um lado negativo: essa abordagem pode ser limitada em termos de customização e profundidade das informações capturadas. Por exemplo, em uma aplicação complexa, como as utilizadas na série Naruto (se você fosse monitorar todos os movimentos e interações entre os personagens), a instrumentação zero-code seria suficiente para capturar os detalhes de cada combate? Provavelmente não. Ela oferece uma visão mais superficial e genérica, ideal para situações onde a velocidade é crucial, mas pode deixar a desejar quando se precisa de um nível maior de controle.

Instrumentação Code-Based: Controle Total

Se a zero-code se trata de velocidade e simplicidade, a instrumentação baseada em código é o oposto: aqui, o desenvolvedor tem controle total. Ao inserir manualmente as chamadas de instrumentação no código, é possível personalizar completamente o que é rastreado e como esses dados são reportados. Isso significa que se você precisa de visibilidade total sobre uma função específica ou fluxo de trabalho, esta é a abordagem ideal.

No entanto, essa flexibilidade vem com um preço. Requer tempo e esforço da equipe de desenvolvimento. É uma escolha particularmente vantajosa quando a aplicação exige monitoramento detalhado em áreas específicas que a instrumentação automática não cobre de forma eficiente. Se voltarmos ao exemplo de Naruto, isso seria como monitorar não só os movimentos de cada personagem, mas também suas intenções, motivações e até o fluxo de chakra. Com a instrumentação baseada em código, você pode capturar tudo isso com precisão, mas precisará trabalhar mais para configurá-la.

Bibliotecas Instrumentadas: O Melhor dos Dois Mundos?

Para aqueles que querem o meio-termo entre a simplicidade da instrumentação zero-code e o controle da code-based, as bibliotecas instrumentadas são uma excelente opção. Elas vêm pré-configuradas com pontos de instrumentação e oferecem integração nativa com o OpenTelemetry. Você pode usá-las para monitorar componentes específicos do sistema sem precisar reinventar a roda.

Bibliotecas populares como frameworks web e sistemas de banco de dados já possuem suporte nativo para OpenTelemetry, o que facilita a adoção e acelera o processo de coleta de dados. Novamente, utilizando o universo de Naruto como exemplo, seria como pegar uma biblioteca pronta para monitorar os combates de cada ninja sem precisar escrever o código para isso do zero. Prático, não?

Conclusão

No final das contas, a escolha entre zero-code, code-based ou bibliotecas instrumentadas vai depender das necessidades do seu projeto e da sua equipe. Se você precisa de uma solução rápida e eficiente, zero-code pode ser a melhor escolha. Mas se o seu foco é controle e precisão, code-based provavelmente será o caminho. Já as bibliotecas instrumentadas oferecem um excelente compromisso entre ambos.

Luis De Llamas

OpenTelemetry: Traces, Métricas, Logs e Baggage

Luis Fabrício De Llamas — Thu, 03 Oct 2024 22:06:09 +0000

Com o avanço das arquiteturas distribuídas e o uso crescente de microserviços, o monitoramento tradicional das aplicações deixou de ser suficiente. Ferramentas que apenas capturam métricas ou logs isoladamente não conseguem fornecer uma visão completa do comportamento de sistemas complexos. É nesse contexto que o OpenTelemetry surge como uma solução robusta, oferecendo uma abordagem unificada para coletar e correlacionar diferentes sinais. Entre esses sinais, estão os traces, as métricas, os logs e o baggage, cada um desempenhando um papel fundamental na jornada rumo à observabilidade completa.

1. O que são Traces?

Os traces são essenciais para rastrear o caminho de uma requisição através de vários serviços em um sistema distribuído. Cada requisição pode passar por diversas camadas e serviços, e os traces registram todas essas interações em detalhes. Isso permite visualizar o fluxo completo de uma transação, desde a entrada no frontend até a interação com o banco de dados, ajudando a identificar onde ocorrem falhas ou lentidões.

Como descrito na documentação oficial do OpenTelemetry, os traces são compostos por spans, que representam cada etapa individual da requisição. Esses spans são então agrupados para formar um trace, que fornece uma visão coesa do fluxo da transação.

2. Métricas: Monitoramento da Saúde do Sistema

As métricas são outro sinal importante fornecido pelo OpenTelemetry. Elas são essenciais para monitorar o desempenho geral do sistema, oferecendo insights sobre o uso de recursos, como CPU e memória, e a taxa de erro de serviços. Enquanto os traces focam na rastreabilidade de uma requisição específica, as métricas proporcionam uma visão macro, permitindo que você monitore a "saúde" da aplicação como um todo.

Por exemplo, métricas como o tempo de resposta médio, o número de requisições por segundo ou a taxa de erros ajudam a identificar padrões e tendências de desempenho, além de alertar sobre possíveis problemas que possam estar afetando o sistema.

3. Logs: Capturando Eventos Críticos

Os logs são usados para registrar eventos significativos no sistema, como erros, transações ou qualquer outro evento relevante. Eles complementam os traces e as métricas, oferecendo contexto adicional sobre o que aconteceu em determinado ponto do tempo.

Enquanto um trace mostra o caminho de uma requisição e uma métrica oferece uma visão numérica sobre o desempenho, os logs trazem detalhes específicos dos eventos que ocorreram. Por exemplo, se uma falha for detectada em um trace, os logs podem fornecer detalhes sobre o erro que causou a falha, ajudando a solucionar o problema de forma mais eficiente.

4. Baggage: Contexto Compartilhado

O baggage é um sinal muitas vezes subestimado, mas que tem um papel crítico no rastreamento de requisições distribuídas. Ele permite que informações contextuais sejam propagadas entre serviços em uma requisição, o que é extremamente útil em sistemas de microserviços. Com o baggage, é possível compartilhar atributos e dados entre diferentes partes do sistema, garantindo que o contexto de uma requisição seja mantido de ponta a ponta.

Por exemplo, imagine que uma requisição passe por vários serviços em diferentes partes do sistema. O baggage garante que atributos como IDs de transações ou dados do usuário sejam transmitidos entre todos os serviços envolvidos, facilitando a correlação de logs, métricas e traces.

A Importância de Combinar Esses Sinais

Cada um desses sinais traces, métricas, logs e *baggage*tem uma função específica, mas é na combinação deles que o verdadeiro poder do OpenTelemetry se revela. Quando utilizados juntos, eles proporcionam uma visão detalhada e coesa de todos os aspectos do sistema. Por exemplo:

Um trace pode mostrar o fluxo completo de uma requisição.
Métricas podem indicar que o tempo de resposta médio aumentou em determinado serviço.
Logs podem fornecer detalhes sobre erros que ocorreram.
O baggage garante que informações críticas estejam disponíveis em cada estágio da requisição.

Essa combinação de sinais possibilita uma observabilidade muito mais rica e detalhada, permitindo que as equipes identifiquem rapidamente onde estão os problemas e como resolvê-los de forma eficiente.

Conclusão

Em um mundo onde arquiteturas distribuídas e microserviços dominam, monitorar e entender o comportamento das aplicações exige mais do que simples métricas ou logs isolados. O OpenTelemetry, com seus sinais integrados de traces, métricas, logs e baggage, fornece a visibilidade necessária para que equipes de DevOps e desenvolvedores possam manter o desempenho ideal de suas aplicações.

Se você ainda não está utilizando todos esses sinais de forma combinada, pode estar perdendo oportunidades de otimizar o monitoramento do seu sistema. Como você tem lidado com a observabilidade de suas aplicações distribuídas? Já utiliza OpenTelemetry? Compartilhe suas experiências nos comentários e siga-me no LinkedIn para mais insights sobre observabilidade e desempenho de sistemas complexos.

Explorando a Observabilidade com OpenTelemetry: Propagação de Contexto e Arquiteturas Distribuídas

Luis Fabrício De Llamas — Wed, 02 Oct 2024 23:53:34 +0000

A observabilidade é um dos pilares para garantir o sucesso de sistemas complexos e distribuídos. Diferente do monitoramento tradicional, que reage a alertas específicos, a observabilidade oferece uma visão ampla e profunda do sistema, baseada em três pilares principais: métricas, logs e rastreamentos (traces). Isso possibilita não só a identificação de problemas, mas também a sua causa raiz, essencial para arquiteturas modernas como microservices.

O Papel do OpenTelemetry

O OpenTelemetry é uma estrutura open-source que facilita a implementação de uma estratégia robusta de observabilidade. Ele unifica a coleta de métricas, logs e rastreamentos distribuídos, padronizando como os dados são capturados e transportados. Dessa forma, mesmo em sistemas distribuídos, onde múltiplos serviços se interconectam, é possível ter uma visão clara do fluxo de dados.

Observabilidade vs Monitoramento

Monitoramento: Coleta dados estáticos para detectar se algo está errado.
Observabilidade: Permite entender por que algo está errado, correlacionando eventos de diversas fontes e serviços.

Um dos desafios enfrentados em arquiteturas distribuídas é garantir que os dados de uma requisição sejam correlacionados entre diferentes serviços. E é aqui que entra a propagação de contexto.

O que é a Propagação de Contexto?

Imagine um cenário onde uma requisição atravessa diversos microsserviços. Como rastrear cada uma dessas interações para entender todo o fluxo? Isso é possível graças à propagação de contexto, que garante que as informações sobre uma requisição (como IDs de rastreamento e spans) sejam passadas de um serviço para outro.

A propagação de contexto é como o fio condutor que liga todas as partes da aplicação, permitindo que você veja o trajeto completo de uma requisição. Esse processo é essencial para entender a performance e localizar problemas em sistemas altamente distribuídos. Sem a propagação de contexto, teríamos visibilidade apenas de partes isoladas do sistema, perdendo a correlação entre eventos.

Um Exemplo com OpenTelemetry:

Vamos imaginar um exemplo prático com o Naruto:

Naruto (Serviço A) pede ao Kakashi (Serviço B) para lhe dar uma missão, e Kakashi consulta o Banco de Dados de Missões (Serviço C). Cada interação precisa ser rastreada de forma que, se algo der errado entre Kakashi e o banco de dados, possamos identificar onde está o erro. O OpenTelemetry facilita isso associando spans (ou trechos de rastreamento) a cada parte da requisição, garantindo que todas as interações sejam correlacionadas.

Mecanismos da Propagação de Contexto

O OpenTelemetry utiliza padrões como o W3C Trace Context ( falaremos mais dele em outra ocasião), que define como o contexto de rastreamento deve ser propagado e lido por diferentes serviços. Esses dados podem ser transmitidos por meio de headers HTTP ou outros protocolos, permitindo a rastreabilidade em uma grande variedade de plataformas e ambientes.

Desafios na Propagação de Contexto

Implementar a propagação de contexto traz alguns desafios:

Sobrecarga de dados: Quanto mais serviços são envolvidos, mais spans e dados precisam ser coletados, processados e armazenados. Isso pode impactar a performance do sistema.
Compatibilidade entre serviços: Todos os serviços devem implementar corretamente a propagação de contexto, ou a cadeia de rastreamento será quebrada, comprometendo a observabilidade.

Conclusão

A observabilidade é indispensável para garantir a eficiência e confiabilidade de arquiteturas distribuídas. O OpenTelemetry desempenha um papel muito importante ao padronizar e simplificar a coleta de métricas, logs e rastreamentos. A propagação de contexto, por sua vez, é o mecanismo que permite rastrear requisições em um sistema distribuído, garantindo que possamos ter uma visão completa de todas as interações, desde o início até o fim.

Para quem está adotando ou pensando em adotar microsserviços, a implementação de uma estratégia sólida de observabilidade, com o OpenTelemetry, é inevitável. E você? Já utiliza o OpenTelemetry no seu ambiente?

Me siga no LinkedIn para acompanhar mais conteúdos com este.

[ptbr] Podman, uma bela opção.

Luis Fabrício De Llamas — Wed, 06 Sep 2023 19:31:43 +0000

Os Benefícios do Podman : Parte 1

O mundo da computação em contêineres é movimentado e em constante evolução, e várias ferramentas estão disponíveis para criar, executar e gerenciar contêineres. O Docker tem sido amplamente popular nesse campo, mas o Podman surgiu como uma alternativa poderosa que oferece diversos benefícios.Neste primeiro posto veremos sobre o que é nos posteriores veremos seu uso junto ao Quarkus.

O Que é o Podman?

O Podman é uma ferramenta de gerenciamento de contêineres de código aberto parecida ao Docker em muitos aspectos. Ele permite criar, executar e gerenciar contêineres Linux, mas com algumas vantagens bem interessantes.

Benefícios do Podman

Sem Dependência de Daemon

Uma das principais vantagens do Podman é que ele não requer um daemon (processo em segundo plano) para executar contêineres. Isso significa que não há necessidade de um processo constante em execução no sistema, como acontece com o Docker. Isso simplifica a configuração e a segurança, tornando o Podman uma escolha atraente para ambientes em que a simplicidade e o isolamento são essenciais.

Compatibilidade com o Docker

O Podman foi projetado para ser compatível com o Docker, o que significa que você pode usar comandos semelhantes aos do Docker para criar e gerenciar contêineres. Isso facilita a transição para o Podman, especialmente se você já estiver familiarizado com o Docker.

Segurança Aprimorada

O Podman oferece recursos avançados de segurança, como namespaces mais rigorosos e suporte a contêineres rootless (sem a necessidade de privilégios de superusuário). Isso ajuda a garantir que os contêineres executados com o Podman sejam altamente isolados e menos propensos a ameaças de segurança.

Pods para Orquestração Simples

O Podman introduz o conceito de "Pods", que são grupos de contêineres que compartilham um namespace de rede. Isso facilita a execução de várias contêineres como uma unidade coesa, o que é útil para aplicações que exigem comunicação próxima entre contêineres.

Exemplos de Comandos Podman

Executar um Contêiner:

podman run -it --rm ubuntu:latest /bin/bash
Este comando inicia um contêiner Ubuntu interativo e remove-o automaticamente após a saída.

Listar Contêineres em Execução:

podman ps
Esse comando exibe uma lista dos contêineres em execução.

Criar um Pod e Adicionar Contêineres:

podman pod create --name mypod podman run -d --name webapp --pod mypod nginx:latest podman run -d --name db --pod mypod postgres:latest
Aqui, criamos um pod chamado "mypod" e adicionamos contêineres web e de banco de dados a ele.

Parar e Remover Contêineres:

podman stop <container_id> podman rm <container_id>
Esses comandos interrompem e removem um contêiner específico.

Se você está procurando uma ferramenta de contêiner que seja fácil de usar e ao mesmo tempo ofereça recursos avançados, o Podman pode ser a escolha certa para você. Na Parte 2 , veremos como os dev services do Quarkus funcionam com o Podman.

Dev Services for Databases

Luis Fabrício De Llamas — Mon, 04 Sep 2023 14:59:39 +0000

Quarkus Dev Services for Java Developers.

When it comes to Java development, agility and efficiency are crucial. One of the challenges developers face is configuring and managing databases for their applications. Quarkus, a modern and efficient Java framework, provides an elegant solution to this problem with its "Dev Services" functionality for databases.

What Are Dev Services?

Dev Services are a feature of Quarkus that allow developers to have a fully configured and ready-to-use database without the need for complex configurations. This is particularly valuable during development and testing when agility is paramount. Quarkus supports various types of databases, including PostgreSQL, MySQL, MariaDB, H2, and others. Here are some of the benefits:

Zero Configuration

You don't need to manually configure the database URL, username, and password in your application. Quarkus does this automatically for you, saving you time and effort.

Automatic Startup

Dev Services automatically start a database server in development mode and during testing. This means you don't need to manually start a server. The application is configured automatically.

Ease of Use

To use Dev Services, simply include the relevant extension for the type of database you want to use (reactive or JDBC). No need to configure a database URL, username, and password. Quarkus provides the database, and you can start coding without worrying about settings.

Configuration Examples for PostgreSQL:

Enabling / Disabling Dev Services for the Database:

You can disable the automatic start of the Dev Services database in the application.properties file using the following configuration:

properties

quarkus.datasource.devservices.enabled=false

License Acceptance for Proprietary Databases:

If you are using a proprietary database such as DB2 or MSSQL, you will need to accept the license agreement. Create a container-license-acceptance.txt file in your project and add the image name and tag of the database, as shown in the example:

properties

src/main/resources/container-license-acceptance.txt

ibmcom/db2:11.5.0.0a
mcr.microsoft.com/mssql/server:2017-CU12

Mapping Volumes for Database Data Persistence:

You can map volumes from the Docker host's filesystem to containers to provide files such as scripts or configurations and to preserve database data. Here's an example:

properties

quarkus.datasource.devservices.volumes."/path/from"=/container/to

In the above example, the directory "/path/from" on the local machine is accessible at "/container/to" in the container.

Connecting to a Database Running as a Dev Service:

You can connect to a database running as a Dev Service in the same way you would with any database running inside a Docker container.

Configuration Reference:

Quarkus offers a wide range of configuration options to meet your project's specific needs. Here are some of the available configuration options:

quarkus.datasource.devservices.enabled: Allows you to explicitly enable or disable Dev Services.
quarkus.datasource.devservices.image-name: Sets the name of the container image to be used.
quarkus.datasource.devservices.container-env: Allows you to set environment variables to be passed to the container.
quarkus.datasource.devservices.container-properties: Allows you to set specific database properties for additional container configuration.
quarkus.datasource.devservices.port: Defines an optional fixed port for the Dev Service instead of a random port.
quarkus.datasource.devservices.init-script-path: Specifies a path to an SQL script to be loaded from the classpath and applied to the Dev Service database.

These configurations can be adjusted according to your project's needs, providing flexibility in using Quarkus Dev Services.

In summary, Quarkus Dev Services significantly simplifies the process of configuring and managing databases for Java developers. With minimal setup, you can start developing and testing your applications quickly and efficiently, saving time and effort. It's a valuable tool for enhancing productivity and accelerating Java application development.