Resumo

  • O README público de pai-auth-ws-client diz Java 8 ou superior e usa a versão 1.0.0 nos exemplos. Seu único commit data de novembro de 2024.
  • A linha de releases mudou: a 1.5.0 elevou java.version, source e target para 17; a 1.5.1 mantém essa base e seu workflow usa JDK 17.
  • O artefato não está ausente. A JitPack entrega POM e JAR 1.5.1; as doze classes observadas têm major 61, e o manifesto informa Build-Jdk 17.0.12.
  • Uma declaração versionada de compatibilidade deve ligar release, runtime mínimo e testado, revisão da documentação e escopo da API PAI, sem substituir os testes e a decisão de cada operador.

A biblioteca chega antes de a incompatibilidade aparecer

O caminho sugerido ao desenvolvedor parece completo. O repositório da LACNIC apresenta um cliente Java para o serviço web de autenticação PAI. A seção de requisitos diz “Java 8 ou superior”. Os exemplos Maven e Gradle apontam para 1.0.0 e avisam que o número deve ser trocado por uma versão publicada na JitPack. Na mesma página, o badge mostra atualmente 1.5.1. Repositório do cliente PAI README no tag 1.5.1 Projeto na JitPack

O gerenciador de dependências consegue buscar essa versão. Pedidos diretos à JitPack retornam o POM e um JAR de 20.580 bytes. O arquivo contém doze classes, todas com major_version 61; o manifesto registra Build-Jdk: 17.0.12. A especificação da JVM associa major 52 ao Java 8 e major 61 ao Java 17. Assim, o limite não é inferido pelo nome da release: está nos bytes que a JVM precisa ler. POM JitPack 1.5.1 JAR JitPack 1.5.1 Formato de classes na especificação da JVM

Essa constatação termina ali. As fontes não mostram um usuário tentando executar 1.5.1 em Java 8, um login rejeitado, uma interrupção do PAI, uma invasão ou uma vulnerabilidade. O runtime do servidor PAI também não pode ser deduzido do cliente. Trata-se de compatibilidade de carregamento do artefato, não de um incidente de autenticação.

Há uma boa defesa para a escolha do Java 17

Manter um cliente de autenticação preso indefinidamente ao Java 8 pode dificultar atualizações e elevar o custo de segurança. Adotar Java 17 na série mais recente pode ser uma decisão prudente. Compatibilidade passada não é promessa automática de compatibilidade eterna; um projeto pode aumentar seu piso e manter, encerrar ou separar uma linha antiga.

A release 1.5.1 mostra consistência técnica. Seu POM define java.version, maven.compiler.source e maven.compiler.target como 17. O workflow público instala o JDK 17 da distribuição Zulu e executa a verificação Maven. O JAR é major 61. Configuração, ambiente de CI e resultado binário concordam. POM do tag 1.5.1 Workflow do tag 1.5.1

O exemplo 1.0.0 também tem contexto legítimo. Ele manda substituir a versão, e o POM original usa source e target 1.8. O README nasceu coerente com o primeiro lançamento. POM do tag 1.0.0

Essas duas defesas tornam o problema mais claro. O erro não é modernizar o código. O ponto fraco é convidar o leitor a atravessar versões sem dizer em qual delas o runtime mínimo muda.

A mudança pública começa na 1.5.0

As tags registram a transição. Da 1.1.0 à 1.4.0, os POMs mantêm source e target explicitamente em 1.8, embora o CI já rode no JDK 17. Eles também repetem a propriedade java.version, primeiro 1.8 e depois 17. Esse estado intermediário não deve ser simplificado: a propriedade é ambígua, mas os alvos explícitos do compilador continuam em 1.8.

Na 1.5.0, java.version, source e target passam juntos para 17. A 1.5.1 conserva o mesmo conjunto. A comparação entre 1.4.0 e 1.5.0 fornece a fronteira observável. POM 1.4.0 POM 1.5.0

O README ficou no ponto inicial. O histórico do GitHub contém um único commit, de 1º de novembro de 2024. Os bytes verificados são iguais em todos os tags de 1.0.0 a 1.5.1 e na branch main. A 1.5.0 foi publicada em 29 de outubro de 2025; a 1.5.1, em 14 de abril de 2026. Os corpos dessas duas releases estão vazios e não registram o novo piso. Histórico do README Releases no GitHub Release 1.5.1

Não é preciso atribuir descuido deliberado. Quem mantém o código vê o requisito em cada build; quem chega pela primeira vez vê a frase de 2024. A diferença de perspectiva basta para produzir a lacuna.

Cada superfície responde a uma pergunta

O JDK de build não prova sozinho o runtime mínimo. Um compilador novo pode gerar classes para um target antigo. A documentação do Maven separa source e target e alerta que target, isoladamente, não assegura toda a compatibilidade de API. Por isso, o bytecode distribuído é uma evidência necessária. Guia do Maven Compiler Plugin

Mesmo o bytecode tem um limite. Major 61 mostra a geração da JVM capaz de entender o formato, não as versões da API PAI testadas. O POM registra configuração; não comprova um login. O workflow registra CI; não identifica a instalação de um associado. Uma release registra identidade; não define por si só uma janela de suporte.

Também não se pode usar a ausência de assets na página de release para afirmar que o artefato não existe. A rota de distribuição declarada é a JitPack, e POM/JAR estão disponíveis. A API de build da JitPack retorna uma combinação estranha—status: ok e mensagem “Not found”, sem módulos nem URL de build—mas a resposta contraditória não supera o download direto.

O cuidado mantém este artigo fora de outras questões. Não há auditoria de assinatura, chave, tarball ou build reproduzível. Não há tentativa de provar qual commit roda num serviço eleitoral. Não se avalia se ASPA ou RTR está ativado. O objeto exclusivo é a correspondência release–runtime.

Um recibo curto, não uma nova autoridade

Uma ficha de compatibilidade por release seria suficiente. Ela pode registrar projeto, tag, commit, coordenadas Maven, target de class, JDK de build, runtime mínimo suportado e runtimes testados. Deve ainda apontar a revisão de documentação válida, o escopo da API/serviço PAI, mudanças incompatíveis, prazo de suporte e ligação para correção ou substituição.

Um digest pode fixar a ficha aos bytes analisados, sem transformar o controle em auditoria de assinatura. “Construído com 17”, “target 17” e “testado em 17 e 21” devem permanecer campos diferentes. “Ainda disponível” e “ainda suportado” também.

Quase todos os insumos já são públicos. O custo marginal é publicar a junção no momento da release, quando ainda é fácil saber por que o piso mudou. O recibo reduz o trabalho de reconstrução; não autoriza a aplicação de ninguém.

O runtime é local; a promessa é pública

A LACNIC controla o repositório, tags e texto. A JitPack controla o artefato derivado que serve. A especificação da JVM controla o significado de major 61. O operador controla sua distribuição Java, testes e implantação. Uma boa matriz não concentra essas decisões: torna os limites verificáveis.

Isso favorece os dois lados. A LACNIC pode modernizar a linha principal sem parecer manter Java 8 na última versão. O operador pode permanecer numa linha antiga com consciência do suporte, planejar a migração ou testar antes de adotar uma atualização urgente.

Software confiável não é software imóvel. É software cuja promessa de compatibilidade muda com um registro tão claro quanto o da própria versão.

Sources

  1. LACNIC: repositório do cliente PAI
  2. LACNIC: README na versão 1.5.1
  3. LACNIC: POM da versão 1.0.0
  4. LACNIC: POM da versão 1.4.0
  5. LACNIC: POM da versão 1.5.0
  6. LACNIC: POM da versão 1.5.1
  7. LACNIC: workflow de build da versão 1.5.1
  8. LACNIC: lista de releases no GitHub
  9. LACNIC: release 1.5.1
  10. LACNIC: histórico de commits do README
  11. JitPack: projeto do cliente PAI da LACNIC
  12. JitPack: POM gerado para 1.5.1
  13. JitPack: JAR da versão 1.5.1
  14. Oracle: especificação da JVM e formato de class
  15. Apache Maven: configuração de source e target