Práticas Modernas de Build no Java/JVM

Artigo original ↗ Discussão no Hacker News ↗

Projetos Java modernos estão lidando com ferramentas de build cada vez mais complexas, colocando a flexibilidade e o rico ecossistema de plugins do Gradle contra a simplicidade, estabilidade e previsibilidade do Maven. Muitos engenheiros relatam que o Gradle permite builds incrementais poderosos e fluxos de trabalho sofisticados, mas dizem que sua DSL imperativa, APIs em mudança e pontos frágeis dificultam a manutenção de longo prazo, levando alguns de volta ao Maven para bases de código corporativas ou de múltiplas equipes. Alternativas como Bazel, Mill, Ant e ferramentas emergentes são citadas como promissoras em desempenho ou simplicidade, mas a maioria concorda que, qualquer que seja o sistema de build escolhido, mantê-lo rápido, homogêneo e ativamente mantido é essencial para evitar dívida técnica.

Gradle vs. Maven (sentimento geral)

  • Muitos veem o Gradle como poderoso, mas perigosamente flexível: scripts podem fazer qualquer coisa, levando a “armadilhas”, estilos inconsistentes entre projetos e falhas de build difíceis de depurar.
  • As queixas incluem APIs instáveis entre lançamentos, múltiplas formas sobrepostas de fazer a mesma coisa, mensagens de erro ruins e a necessidade de um “especialista em Gradle” em projetos maiores.
  • O Maven é elogiado por ser mais simples, mais previsível e estável por longos períodos; um POM que funciona hoje provavelmente funcionará daqui a uma década.
  • Vários descrevem uma jornada “em três etapas”: odiar a rigidez do Maven → adotar uma ferramenta flexível (Ant/Gradle) → sofrer com a manutenção → voltar ao Maven.

Desempenho e builds incrementais

  • O Gradle recebe crédito por um grafo de tarefas adequado, builds incrementais, cache de testes e boa escalabilidade para grandes projetos multi-módulo, desde que tarefas/plugins sejam escritos corretamente.
  • Outros relatam builds do Gradle não determinísticos que exigem limpezas manuais, especialmente em Android, e percebem o Gradle como lento para configurar até mesmo projetos triviais.
  • Historicamente, o Maven recompila amplamente quando algo muda; versões mais novas do Maven melhoram builds incrementais, mas o comportamento padrão do compilador ainda é bastante propenso a recompilar.
  • Alguns usuários acabam deixando o Maven mais lento por sempre executar clean por hábito.

Casos de uso e pressão do ecossistema

  • O Gradle é, na prática, obrigatório para Android e fortemente favorecido para Kotlin por oferecer suporte de primeira classe, documentação e ecossistema de plugins.
  • O Maven se encaixa em projetos de estilo corporativo com muitos colaboradores ocasionais, onde homogeneidade e convenção em vez de configuração são valiosas.
  • Configurações multi-módulo: o Maven oferece suporte, mas pode se tornar difícil de manejar; alguns recomendam Gradle se você insiste em grandes repositórios com múltiplos projetos.

Outras ferramentas e abordagens

  • O Bazel recebe elogios para Java/monorepos, forte cache e suporte embutido a uber-jar, embora alguns o considerem mais difícil de usar ou sensível à plataforma.
  • Mill e Ant (com scripts compartilhados importados) são mencionados como alternativas mais simples para certas equipes.
  • Esforços mais novos como o Amper da JetBrains (YAML sobre Gradle) buscam simplificar os 95% dos casos de uso comuns.

Temas gerais de prática de build

  • Não empurre lógica customizada complexa para dentro de Maven/Gradle quando um pequeno script bastaria.
  • Mantenha ferramentas de build, plugins e dependências atualizados incrementalmente; configurações de build negligenciadas tornam-se dívida técnica significativa.
  • Alguns gostariam que os sistemas de build Java fossem mais declarativos e mínimos, mas outros observam que projetos reais exigem testes, codegen, cobertura, verificações de segurança, empacotamento e implantação, o que justifica ferramentas mais ricas.