Caramelo
Java Moderno: Elevando o Nível com Imutabilidade, Switch Expressions e Pattern Matching
Introdução
Este artigo fecha um ciclo. Ao longo da série Objects · Immutability · Switch · Pattern Matching, cada tema preparou o terreno para o próximo: começamos nos contratos fundamentais de Object, passamos pela imutabilidade, modernizamos o switch e mergulhamos no Pattern Matching até chegar no ponto onde tudo converge, a exaustividade verificada pelo compilador.
Aqui você encontra as peças conectadas. E o fio condutor é um só: erros que antes explodiam em produção agora nem compilam.
Records, Record Patterns e Sealed/Hidden Classes aparecem de passagem neste artigo porque cada um merece (e vai ganhar) um aprofundamento próprio em artigos dedicados.
1. Objects: os Contratos que Sustentam Tudo
O pitfall clássico: == vs equals()
Todo desenvolvedor Java já caiu ou vai cair nessa armadilha. O operador == compara referências (os dois lados apontam para o mesmo objeto?), enquanto equals() compara conteúdo. O perigo é que às vezes == parece funcionar:
Integer a = 127;
Integer b = 127;
System.out.println(a == b); // true (cache de Integer entre -128 e 127)
Integer c = 128;
Integer d = 128;
System.out.println(c == d); // false (fora do cache, objetos distintos)
String x = "java";
String y = "java";
System.out.println(x == y); // true (String Constant Pool)
String z = new String("java");
System.out.println(x == z); // false (instância fora do pool)
O código que "funciona" com == graças ao cache de Integer ou ao String Constant Pool é uma bomba-relógio: basta o valor sair da faixa do cache ou a String vir de fora do pool (input do usuário, banco, API) para o comportamento mudar. A regra é simples: para conteúdo, sempre equals().
O novo equals() com instanceof e Flow Scoping
E por falar em equals(), o Pattern Matching aposentou o ritual clássico de implementá-lo. Compare:
// ✗ O ritual antigo
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null || getClass() != obj.getClass()) return false;
Produto other = (Produto) obj;
return nome.equals(other.nome) && preco.equals(other.preco);
}
// ✓ Com Type Pattern (JDK 16+)
@Override
public boolean equals(Object obj) {
return obj instanceof Produto p
&& nome.equals(p.nome)
&& preco.equals(p.preco);
}
Três detalhes fazem a versão nova brilhar:
- Null-safety de graça:
null instanceof Produtoretornafalse, então a checagem explícita de nulo desaparece - Sem cast manual: a binding variable
pjá nasce com o tipo certo - Flow scoping:
psó existe onde o compilador prova que o teste passou. No&&seguinte, o acesso ap.nomeé garantidamente seguro
O flow scoping é mais esperto do que parece. Ele funciona inclusive em negações:
public void processar(Object obj) {
if (!(obj instanceof String s)) {
return; // se não é String, sai
}
// s disponível aqui: o compilador sabe que só se chega
// neste ponto se o instanceof foi verdadeiro
System.out.println(s.toUpperCase());
}
Receiver Parameter: o this explícito que quase ninguém conhece
Fechando o bloco de Objects, um recurso obscuro que rendeu boas discussões na série: desde o Java 8, métodos de instância podem declarar o próprio this como primeiro parâmetro, o chamado receiver parameter:
public class Conta {
public void depositar(Conta this, BigDecimal valor) {
// comportamento idêntico ao método sem o receiver parameter
}
}
Ele não muda a semântica nem a assinatura em bytecode. Existe por um único motivo: permitir anotações de tipo sobre o this, algo útil para frameworks de análise estática como o Checker Framework:
public void encerrar(@Locked Conta this) { ... }
É o tipo de detalhe que separa quem decora sintaxe de quem entende o design da linguagem.
2. Immutability: Estado que Não Trai
A série dedicou um artigo inteiro ao custo cognitivo da imutabilidade de Strings: verbos como replace() e toUpperCase() soam como mutação, mas são fábricas de novos objetos. O resultado precisa ser capturado, senão é descartado em silêncio.
A lição se generaliza: imutabilidade elimina categorias inteiras de bug, principalmente em concorrência. E o Java moderno vem empurrando o ecossistema nessa direção em detalhes que passam despercebidos.
Antes e depois: Collectors.toList() vs toList()
Um exemplo perfeito está na Stream API. Compare:
// ✗ Antes (e ainda muito comum em code review)
List<String> nomes = clientes.stream()
.map(Cliente::nome)
.collect(Collectors.toList());
// ✓ Depois (JDK 16+)
List<String> nomes = clientes.stream()
.map(Cliente::nome)
.toList();
A diferença vai além da estética:
Collectors.toList() |
Stream.toList() |
|
|---|---|---|
| Desde | JDK 8 | JDK 16 |
| Mutabilidade | Sem garantia (hoje retorna ArrayList mutável) |
Lista não modificável |
| Contrato | Implementação pode mudar | Imutabilidade documentada |
| Verbosidade | Import + chamada longa | Direto na stream |
O detalhe importante: Stream.toList() retorna uma lista não modificável. Qualquer add() ou remove() posterior lança UnsupportedOperationException. Isso é imutabilidade como default, o mesmo princípio das Strings aplicado às coleções que sua pipeline produz. Se o código adiante realmente precisa mutar a lista, a intenção fica explícita: new ArrayList<>(stream.toList()).
3. Switch Expressions: De Instrução a Expressão
O switch clássico era uma instrução de controle de fluxo com uma pegadinha embutida: o fall-through silencioso quando alguém esquece o break. O JEP 361 (JDK 14) transformou o switch em uma expressão que retorna valores.
Arrow syntax: o fim do fall-through acidental
// ✗ Antes: break esquecido = bug silencioso
String turno;
switch (hora) {
case 6, 7, 8, 9, 10, 11:
turno = "manhã";
break; // esqueceu? cai no próximo case
case 12, 13, 14, 15, 16, 17:
turno = "tarde";
break;
default:
turno = "noite";
}
// ✓ Depois: cada braço é isolado por design
String turno = switch (hora) {
case 6, 7, 8, 9, 10, 11 -> "manhã";
case 12, 13, 14, 15, 16, 17 -> "tarde";
default -> "noite";
};
yield substitui o break
Quando um braço precisa de um bloco com lógica, quem devolve o valor é o yield. E aqui vale desfazer uma confusão comum: yield não é um break renomeado. O break interrompia fluxo; o yield produz o valor da expressão:
int taxa = switch (categoria) {
case PREMIUM -> 0;
case PADRAO -> {
int base = calcularBase();
yield base + ajusteSazonal(); // yield entrega o valor do braço
}
};
A distinção semântica importa: numa switch expression não existe "sair sem valor". Todo caminho precisa produzir um resultado, e o compilador cobra isso. É o primeiro sinal da exaustividade que vamos ver adiante.
case null: o fim do boilerplate if (obj == null)
Por décadas, todo switch sobre referência exigia uma guarda externa, porque seletor nulo lança NullPointerException:
// ✗ O ritual de sempre
if (obj == null) {
return "sem valor";
}
return switch (obj) { ... };
Com o Pattern Matching para switch (preview no JDK 17 via JEP 406, finalizado no JDK 21 via JEP 441), o nulo virou um rótulo de primeira classe:
// ✓ Nulo tratado dentro do próprio switch
String resultado = switch (obj) {
case null -> "sem valor";
case String s -> "texto: " + s;
default -> "outro tipo";
};
Sem o case null declarado, o comportamento tradicional se mantém: NullPointerException. Ou seja, código legado não muda de comportamento, mas código novo pode finalmente tratar o nulo onde ele pertence.
4. Desvendando o Pattern Matching
Pattern Matching é o mecanismo que testa a forma de um valor e, no mesmo movimento, extrai dados para binding variables. A pergunta deixa de ser "que tipo é isso?" seguida de um cast, e vira uma única operação declarativa.
O switch aceita qualquer objeto
Até o JDK 20, o seletor do switch era restrito a inteiros, enums, Strings e pouco mais. Com o JEP 441, qualquer referência serve como seletor, e os rótulos aceitam padrões de tipo:
String descreve(Object obj) {
return switch (obj) {
case Integer i -> "inteiro de valor " + i;
case String s -> "texto de tamanho " + s.length();
case null -> "nulo";
default -> "tipo não mapeado";
};
}
O que era uma escada de if-else com instanceof e cast vira uma estrutura onde cada forma possível do dado tem seu lugar declarado.
Guarded Patterns: refinando com when
O padrão de tipo responde "é uma String?". O guarded pattern acrescenta "e ela me interessa?". A cláusula when (JDK 21) anexa uma condição booleana ao padrão, com a binding variable disponível dentro da guarda:
String classifica(Object obj) {
return switch (obj) {
case String s when s.isBlank() -> "texto em branco";
case String s when s.length() > 10 -> "texto longo";
case String s -> "texto curto";
case Integer i when i > 0 -> "positivo";
case Integer i -> "zero ou negativo";
default -> "outro";
};
}
Dominância: a ordem importa
E o exemplo acima só compila porque respeita a regra de dominância: o primeiro match vence, então padrões mais específicos precisam vir antes dos mais genéricos. Inverta a ordem e o compilador recusa o código:
// ✗ Não compila: String s domina o padrão guardado abaixo
switch (obj) {
case String s -> "qualquer texto";
case String s when s.isBlank() -> "em branco"; // inalcançável
}
A regra prática: constantes e padrões guardados primeiro, padrões de tipo puros depois, o caso mais genérico por último. Diferente do fall-through de antigamente, que falhava em silêncio, aqui a ordem errada é erro de compilação. O compilador de novo agindo antes do bug.
Generics no Pattern Matching: o fantasma do Type Erasure
A série já tinha visitado o Type Erasure, e ele reaparece aqui impondo um limite: não dá para testar o parâmetro genérico em runtime, porque ele não existe mais lá.
// ✗ Não compila: erasure impede verificar o <String> em runtime
if (obj instanceof List<String> ls) { ... }
// ✓ Compila: o wildcard não promete nada sobre o elemento
if (obj instanceof List<?> l) { ... }
Dentro de contextos genéricos, porém, o Pattern Matching colabora com a inferência. Um método genérico pode fazer dispatch por tipo mantendo a assinatura flexível:
static <T> String processa(T valor) {
return switch (valor) {
case Integer i -> "número: " + i;
case String s -> "texto: " + s;
case List<?> l -> "lista com " + l.size() + " elementos";
case null -> "nulo";
default -> "tipo genérico não mapeado";
};
}
A regra mental: o Pattern Matching enxerga o que sobrevive ao erasure. Tipos brutos e wildcards sim, parâmetros genéricos concretos não.
Pattern Matching + Predicate: composição funcional
Uma combinação elegante que rendeu um post próprio na série: usar Type Patterns dentro de Predicate para construir filtros type-safe e componíveis:
Predicate<Object> textoRelevante =
obj -> obj instanceof String s && !s.isBlank() && s.length() > 3;
Predicate<Object> numeroPositivo =
obj -> obj instanceof Integer i && i > 0;
List<Object> relevantes = entradas.stream()
.filter(textoRelevante.or(numeroPositivo))
.toList();
O binding funciona normalmente dentro da lambda, e a composição via and(), or() e negate() continua disponível. É Pattern Matching saindo do if e do switch para viver no mundo funcional, com o toList() imutável da seção 2 fechando a pipeline.
5. Exaustividade: Onde Tudo se Encaixa
Todo switch com padrões precisa ser exaustivo: cobrir todos os valores possíveis de entrada. Esqueceu um caso? O código nem compila.
Existem três formas de garantir a completude. O default clássico funciona, mas esconde o problema debaixo do tapete. Um padrão total como case Object o é um pega-tudo mais elegante, mas continua pega-tudo. E a terceira forma é onde o compilador mostra seu poder: quando a hierarquia é selada, tratar cada subtipo permitido prova que a lógica está completa, sem default nenhum:
sealed interface Player permits Tennis, Football { }
String descreve(Player player) {
return switch (player) {
case Tennis t -> "joga tênis";
case Football f -> "joga futebol";
}; // exaustivo, sem default
}
A recompensa vem na manutenção: se daqui a seis meses alguém adicionar Golf à hierarquia, todo switch sobre Player quebra na compilação apontando exatamente onde o novo caso não foi tratado. Com um default genérico, o Golf passaria batido e viraria bug silencioso em produção.
error: the switch expression does not cover all possible input values
💡 No IntelliJ, um Alt+Enter no switch quebrado oferece "Add remaining branches" e gera o case que falta. Refatorar hierarquia selada vira uma sequência de Alt+Enter pelo projeto.
Sealed Classes, Hidden Classes, Records e Record Patterns merecem mais do que um parágrafo, e por isso ganham artigos dedicados na sequência. Por ora, fica o essencial: a exaustividade é o ponto onde a série inteira converge. O equals() limpo do bloco de Objects, o estado imutável do bloco de Immutability, o switch que produz valores e o Pattern Matching que decompõe tipos, tudo culmina no compilador provando que nenhum cenário ficou de fora.
Conclusão
O Java moderno foca em expressividade e segurança em tempo de compilação, e a série mostrou esse movimento em camadas. Nos fundamentos, equals() com Type Pattern e flow scoping aposentou o ritual de null-check e cast, enquanto o pitfall de == vs equals() segue lembrando que referência não é conteúdo. Na imutabilidade, das Strings ao toList() da Stream API, o default da linguagem caminha para estado que não trai. No switch, a arrow syntax e o yield acabaram com o fall-through, e o case null enterrou o boilerplate de guarda. E no Pattern Matching, guarded patterns, dominância, generics e Predicates formam um vocabulário novo para expressar lógica de negócio, coroado pela exaustividade.
O padrão comum a tudo: muito mais intenção, e uma classe inteira de bugs eliminada antes do primeiro deploy.
Isso fecha a série Objects · Immutability · Switch · Pattern Matching. E abre a próxima: Records, Record Patterns e Sealed/Hidden Classes em profundidade. O Java continua evoluindo, e quem domina esse alicerce escreve código limpo, seguro e profissional.
Este artigo fecha a série Objects · Immutability · Switch · Pattern Matching do getcaramelo.dev.
Tem dúvidas ou quer aprofundar algum ponto? Me encontra no LinkedIn ou no GitHub.
Gostou do conteúdo? Me segue no @getcaramelo.dev