Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Tem um cenário em Java 21 que confunde bastante quando a modelagem usa sealed: você cobre todos os subtipos aparentes no switch e, ainda assim, o compilador continua dizendo que a expressão não é exaustiva. O ponto que mais confunde é simples: sealed restringe quem pode herdar, mas não transforma a classe em abstract automaticamente. Se você deixa um tipo intermediário concreto, o compilador ainda considera que ele pode existir em runtime. Logo, o switch deixa de ser exaustivo. ## Exemplo adaptado
sealed class Evento permits Sucesso, Falha {} sealed class Falha extends Evento permits FalhaValidacao, FalhaInfra {} final class Sucesso extends Evento {}
final class FalhaValidacao extends Falha {}
final class FalhaInfra extends Falha {}return switch (evento) { case Sucesso s -> "ok". case FalhaValidacao f -> "validacao". case FalhaInfra f -> "infra". }. Evento e Falha continuam concretos, ainda seria possível ter uma instância de new Evento() ou new Falha(). O compilador está certo em reclamar. ## O que resolve de verdade - Tornar os tipos intermediários abstract sealedsealed interfacedefault / case Evento e ->... quando o domínio ainda não estiver fechado ## Leitura prática Quando eu quero exaustividade forte, meu checklist fica assim: - Os nós intermediários da árvore são abstratos?switch está refletindo o domínio real ou só a hierarquia que eu imaginei? Achei um excelente lembrete de que exaustividade não depende apenas do switch. ela depende principalmente da modelagem do domínio. Se a árvore permite valores intermediários, o compilador vai cobrar. Queria ouvir como vocês estão modelando isso em projetos com Java 21, pattern matching e hierarquias mais profundas.
O detalhe que pouca gente coloca na conta é SLO. Dá para animar com Java/Spring, mas alguém vai ter que sustentar isso no dia a dia.
Essa pauta fica mais útil quando separa promessa de rotina. No papel Java/Spring parece simples. na prática pesa em rollback.
Isso parece bom para começar, mas eu queria comparar antes e depois. Principalmente em rollback, porque é ali que o custo aparece quando o time muda
Java/Spring sem rollback vira dor depois
kkkk
O ponto de Java/Spring faz sentido, mas eu olharia primeiro para rollback. Se isso não fica claro, a novidade só troca um gargalo por outro.
Eu levaria isso para um piloto bem limitado. Se tutorial não melhorar sem piorar rollback, melhor parar cedo.
Eu gosto da discussão quando ela sai do demo. Em Java/Spring, o que decide é ter um teste pequeno, responsável claro e caminho para voltar atrás.
Quem fica responsável por risco quando o primeiro dev que puxou isso sair do projeto?
boa pauta para comparar com um caso ruim
rollback primeiro, hype depois
Para mim a pergunta prática é onde tutorial entra no fluxo real. Sem esse recorte, fica fácil vender ganho e esquecer manutenção.
O detalhe que pouca gente coloca na conta é decisão. Dá para animar com Java/Spring, mas alguém vai ter que sustentar isso no dia a dia.
eu queria ver esse recorte em produção também
👍
Uau, isso muda bastante quando entra produção
Eu testaria isso pequeno antes de virar padrão
Tem valor, só não compraria como regra geral. O contexto de Java/Spring precisa mostrar quem opera, quem revisa e o que acontece quando falha.
O que seria sinal de parar esse teste antes de virar padrão?
A pergunta que eu faria é: quem cuida de rollback quando esse Java/Spring sair da fase de empolgação?