Project Valhalla, Explicado: Como uma Década de Trabalho Chega ao JDK 28

Escopo e objetivos do Project Valhalla

• O debate concorda que os principais objetivos do Valhalla são:
  • Classes de valor sem identidade.
  • Layouts mais densos e achatados (especialmente para arrays).
  • Retrofit de tipos existentes (por exemplo, wrappers como Integer) como classes de valor sem mudanças no código-fonte.
• Muitos enfatizam a dificuldade de fazer isso de forma compatível com versões anteriores em um ecossistema de 30 anos, em comparação com projetar structs em um runtime novo.

Comparação com .NET, C#, e outras linguagens

• Comparações recorrentes com structs de C# e generics reificados:
  • Alguns dizem que Java está “apenas correndo atrás” de recursos de longa data do .NET e que o artigo exagera a novidade.
  • Outros argumentam que o .NET tinha menos restrições legadas; adicionar isso à JVM mantendo binários antigos em execução não é trivial.
• Debate sobre fibers/threads virtuais versus async/await:
  • Alguns veem threads virtuais como estritamente melhores do que funções async “coloridas”.
  • Outros apontam trade-offs; não há consenso de que sejam “objetivamente melhores”.

Debates sobre nulabilidade e sistema de tipos

• Forte discordância sobre a falta de segurança contra null no Java:
  • Alguns veem o Valhalla como uma oportunidade perdida de corrigir null no nível do tipo.
  • Outros apontam um JEP rascunho para tipos com restrição de null (T!) e planos para contextos de “tudo aqui é non-null” em nível mais amplo.
• Disputa sobre se a nulabilidade deve ser uma propriedade de tipos ou de variáveis.
• Comparações com as abordagens de Kotlin, C#, Hack, Go e Rust; não há consenso sobre o “modelo certo”.

Semântica: identidade, igualdade e encapsulamento

• Classes de valor não têm identidade; == passa a ser comparação bit a bit/de estado:
  • Alguns celebram isso; outros se preocupam com vazamento da representação interna (por exemplo, diferentes formas não normalizadas de frações comparando como diferentes).
• Integer/Long/Double se tornando classes de valor:
  • Reconhecido como uma rara mudança incompatível: código existente que depende de identidade por referência ou de comportamento peculiar de boxing pode mudar ou falhar.
• Ficou esclarecido que classes de valor devem ser imutáveis (campos efetivamente finais).

Desempenho, limites de flattening e tearing

• A prévia atual só achata arrays de classes de valor cuja representação do elemento (incluindo o marcador de null) caiba no tamanho de escrita atômica da plataforma (muitas vezes 64 bits):
  • Céticos dizem que isso limita os benefícios principalmente a tipos pequenos e primitivos boxed.
  • Defensores observam que trabalhos futuros (tipos com restrição de null, semântica “tearable”) ainda virão e que a scalarização de locais continua útil.
• Há preocupação de que scalarização/flattening possam falhar de formas opacas, tornando o desempenho imprevisível; alguns prefeririam erros em tempo de compilação a fallbacks silenciosos para heap.

Evolução e manutenção do Java

• Sentimento dividido:
  • Críticos acusam o Java de excesso de conservadorismo, oportunidades perdidas (segurança contra null, design de generics) e complexidade.
  • Defensores destacam melhorias rápidas e incrementais (GCs, threads virtuais, records, sealed types), forte compatibilidade retroativa, e argumentam que o Java está em seu melhor momento, apesar do ceticismo do HN.

Meta: qualidade do artigo

• Vários comentaristas criticam:
  • Texto e imagens aparentemente gerados por IA.
  • Imprecisões técnicas (história de hardware, exemplos ignorando limites de 64 bits).
• Alguns dizem que isso mina a confiança na explicação, mesmo que os JEPs subjacentes sejam sólidos.