Quando você compilaria um serviço Java para uma native image, e o que você abre mão?

Native image serve para cargas em que tempo de startup e memória dominam: funções serverless, ferramentas de linha de comando e serviços que escalam para zero, já que ela inicia em milissegundos sem aquecimento e com footprint bem menor. O custo é a suposição de mundo fechado, então reflexão, proxies dinâmicos e carregamento de recursos precisam ser conhecidos em tempo de build, os builds são lentos, e o throughput de pico pode ser menor do que o JIT alcança num processo de longa duração.

Eu apelo para isso quando o tempo de startup está no caminho crítico. Uma função que roda por duzentos milissegundos não pode bancar uma JVM que leva três segundos para subir e mais um minuto para aquecer, e o mesmo argumento vale para uma ferramenta de linha de comando ou um serviço que escala para zero entre picos de tráfego. Memória é o outro ganho, já que uma native image roda numa fração do heap. O que você abre mão é o dinamismo. Compilação ahead of time assume um mundo fechado, então qualquer coisa descoberta em runtime, reflexão, proxies dinâmicos, service loading, resource bundles, precisa ser declarada em tempo de build. Frameworks modernos geram a maior parte dessa configuração para você durante o passo de build, mas uma biblioteca que faz algo esperto em runtime vai falhar de um jeito que só aparece no binário nativo, então a suíte de testes precisa rodar contra a imagem também. Builds também levam minutos em vez de segundos, e o ferramental de observabilidade é menos maduro. Para um serviço de longa duração com tráfego constante eu fico na JVM, porque o JIT acaba batendo código compilado ahead of time no throughput de pico.