JEP 401: Value Objects (Preview) mesclado ao master do OpenJDK

Artigo original ↗ Discussão no Hacker News ↗

O Project Valhalla, de longa duração no Java, alcançou seu primeiro grande marco no OpenJDK: os preview “value objects”, um novo tipo de classe sem identidade de objeto, projetado para trazer desempenho semelhante ao de structs enquanto preserva as fortes garantias de memória e concorrência do Java. Os comentadores veem isso como aproximadamente “metade” do Valhalla e a parte mais importante, permitindo melhor uso de generics e layouts de dados mais eficientes, ao mesmo tempo em que observam o trabalho restante em nulabilidade, generics especializados e tipos de valor tearable. A mudança também provoca reflexões mais amplas sobre a evolução cautelosa e retrocompatível do Java, seu foco em desempenho em comparação com C# e JavaScript, e a distância entre a linguagem moderna e seu ecossistema enterprise pesado.

Escopo do Project Valhalla e do JEP 401

  • O JEP 401 (Value Objects, Preview) foi mesclado; é visto como a primeira e crucial metade do Project Valhalla (aproximadamente “~50%” da visão).
  • O trabalho restante inclui generics especializados, APIs SIMD/vector, generics reificados e tipos não anuláveis.
  • Muitos comentadores dizem que isso, por si só, já torna o Valhalla um sucesso, especialmente para desempenho.

Value Objects: Semântica e Desempenho

  • Os value objects são descritos como “semelhantes a structs”: sem identidade, imutáveis, flattenable quando possível, com grandes benefícios de memória e cache.
  • O design enfatiza “integrity by default”: semântica segura e garantias fortes, com opções de desempenho como opt-ins explícitos.
  • Um enquadramento de design divide os dados em quatro categorias: objetos clássicos, objetos sem identidade, valores atômicos e valores “tearable” (“clássicos”).

Integer, Identidade e Strings

  • Integer e wrappers semelhantes tornam-se value classes, perdendo identidade de objeto; muitos observam que Integer já se comporta de forma “value-like” devido ao pooling e ao hashCode.
  • Projetos que dependem da identidade de Integer tiveram anos de aviso; algumas ferramentas de nicho (por exemplo, runtimes de linguagem voltados para a JVM) podem ser impactadas.
  • Strings não podem se tornar tipos de valor totalmente indistinguíveis principalmente por compatibilidade retroativa e restrições técnicas em torno de arrays de suporte de tamanho variável; os ganhos, de todo modo, são vistos como limitados.

Atomicidade, Tearability e Limites de Tamanho

  • A discussão gira em torno da atomicidade: classes de valor não devem “tear” a menos que sejam explicitamente marcadas como tearable.
  • O modelo atual vincula o flattening de referências ao tamanho da palavra da máquina (por exemplo, 63 bits + bit de null); valores maiores podem existir, mas não podem ser flattenados da mesma forma.
  • Alguns argumentam que outras plataformas (por exemplo, .NET, CPUs com atomics de 128 bits) mostram trade-offs diferentes; outros enfatizam que o modelo de memória e as garantias de segurança do Java determinam o design.

Compatibilidade Retroativa e Migração

  • Há grande apreço pela estabilidade de longo prazo do Java: código antigo normalmente continua funcionando sem mudanças; alterações quebráveis são raras, bem sinalizadas e restritas.
  • Exemplo: sincronizar em instâncias de Integer eventualmente vai quebrar quando elas se tornarem value objects.
  • A semântica de valor é no local de declaração, não no local de uso, para garantir que imutabilidade e segurança possam ser impostas pela própria classe.

Processo e Governança do OpenJDK

  • O PR compacta milhares de commits em um só por meio de um bot; o histórico detalhado é preservado em ferramentas separadas, não no Git.
  • Alguns não gostam do histórico do Git “destruído”; outros argumentam que o processo é intencional para evitar lock-in do GitHub e manter as ferramentas externas portáveis.
  • O trabalho em Valhalla é relatado como sendo, de forma esmagadora, conduzido pela Oracle, com elogios à disciplina e à visão de longo prazo em comparação com a cultura típica de “ship early”.

Impacto no Ecossistema

  • Espera-se uma melhora significativa de desempenho para Java e linguagens de JVM de nível mais alto, como Scala, especialmente onde hoje a abstração é custosa.
  • Generics sobre tipos de valor e melhor especialização de layout são destacados como grandes ganhos futuros.

Linguagem Java, Cultura e Comparações

  • Muitos expressam forte entusiasmo pelo Java moderno: records, lambdas, streams, virtual threads, structured concurrency e, agora, value objects.
  • Vários argumentam que o Java evoluiu de forma mais limpa que o C# (visto por alguns como excessivamente complicado) e mantém um modelo mais simples (value vs reference + Valhalla).
  • Uma crítica persistente é à “cultura enterprise”: frameworks verbosos (especialmente Spring), nomes de classes longos e bases de código enormes; outros respondem que isso é cultural, não inerente ao Java.
  • Menções positivas a frameworks mais leves (por exemplo, Helidon, Quarkus) e a designs centrados em virtual threads.
  • O Java é repetidamente contrastado com JavaScript: sintaxe de superfície semelhante, mas objetivos muito diferentes; o Java é visto como à frente em recursos como data/time moderno, switch expressions e agora value objects.

Ferramentas e CLI

  • Alguns gostariam de uma CLI unificada mais “batteries-included”, à la Go, para build/test/format/lsp, em vez da fragmentação atual (Maven, Gradle, etc.).
  • O Maven é apreciado pela estabilidade, mas seu XML e modelo de atualização são criticados; o Gradle é visto como poderoso, mas sensível a versões.