Project valhalla chega ao jdk 28: jep 401 redefine semântica de `==` para objetos de valor

O JEP 401 (Value Objects - Preview) foi integrado ao JDK 28, marcando a primeira entrega tangível do Project Valhalla. A proposta introduz value classes, instâncias sem identidade, compostas exclusivamente por campos final - e redefine a semântica do operador == para esses tipos, comparando estrutura e não referência.

O que muda para o desenvolvedor

Uma classe declarada com o modificador value torna-se uma value class; todas as demais permanecem identity classes. As regras de construção são estritas:

• Campos de instância são implicitamente final;

  Leia também Web Summit Rio 2026 define datas e confirma palestrantes de peso no Riocentro arrow_forward

• Todos os campos devem ser inicializados antes que a instância se torne observável;

• Métodos de instância não podem ser synchronized;

• Records também aceitam o modificador: value record Color(byte r, byte g, byte b) {}.

A verificação bytecode que garante essas regras vem do JEP 539 (Strict Field Initialization). O recurso está desabilitado por padrão, exige --enable-preview em tempo de compilação e execução.

O novo ==: igualdade por conteúdo

Para identity objects, o comportamento de == não muda. Para value objects, o operador retorna true quando ambos operandos são da mesma classe e possuem os mesmos valores de campo (campos de referência são comparados recursivamente com ==).

value class Point { int x; int y; }

Point p1 = new Point(3, 4);
Point p2 = new Point(3, 4);
assert p1 == p2; // true: mesma classe, mesmos campos

Object o1 = p1, o2 = p2;
assert o1 == o2; // true: ainda indistinguíveis como Object

String s1 = "hamburger\);
String s2 = new String(s1);
assert s1 != s2; // true: String continua sendo identity class

Atenção: o JEP 401 não propõe == como substituto de equals(). A recomendação de usar equals() para comparação semântica permanece, pois o estado interno de um value object nem sempre equivale ao estado que ele representa.

Migração de classes do jdk

Com a preview habilitada, diversas classes value-based do JDK, wrappers primitivos (Integer, Double, etc.) e LocalDate, entre outras, passam a ser value classes. Com a preview desabilitada, o compilador mantém suas formas de identidade e o comportamento alinhado ao JDK 27.

• Código compilado com preview precisa rodar com preview habilitado;

• Recompilação é recomendada para classes migradas, o atributo LoadableDescriptors no class file informa à JVM que a classe é uma value class;

• Algumas APIs deixam de funcionar: criar Reference para value object lança IdentityException;

• O javac estende seus avisos de identidade para value classes no JDK 28.

Ganhos de performance: otimização, não garantia

O payoff esperado é otimização da JVM, não resultado de benchmark garantido. A JVM pode:

• Scalarizar o value object em seus campos constituintes;

• Achatar (flatten) em representação compacta armazenada diretamente em campo ou elemento de array;

• Fazer fallback para alocação ordinária quando nenhuma otimização se aplica (especialmente durante warmup, antes de código JIT otimizado estar disponível).

O achatamento permanece limitado pela atomicidade; em plataformas típicas, a codificação disponível pode ser tão pequena quanto 64 bits incluindo flag de null.

Motivação: desalinhamento entre intenção e garantia

O JEP enquadra o problema como um mismatch entre o que desenvolvedores querem (tipos pequenos que carregam dados, número complexo, cor de pixel, data) e o que Java garante: todo new produz algo distinguível de qualquer outro objeto. Para esses tipos, a identidade é frequentemente irrelevante e prejudicial.

A identidade carrega custo de execução: alocação por objeto, desreferência a cada uso, pressão no GC e degradação de localidade. Escape analysis recupera parte disso, mas suas otimizações são imprevisíveis e não ajudam quando o objeto escapa (ex.: armazenado em campo ou array).

Impactos e considerações de segurança

• Desenvolvedores podem se surpreender com o novo comportamento de == e synchronized, embora a proposta espere disrupções incomuns e gerenciáveis;

• O bytecode if_acmpeq ganha verificação adicional para value objects, mantendo o caso de identidade como fast path;

• Duas considerações de segurança: == e identityHashCode podem expor indiretamente valores de campos private; comparar duas árvores grandes de value objects pode consumir tempo ilimitado.

Fonte original: InfoQ — https://www.infoq.com/news/2026/08/jep401-value-objects-preview/ (10/08/2026).