[quote=ViniGodoy]Só marcar como deprecated causa uma explosão de métodos duplicados.
Por exemplo, você teria que criar um novo setDefaultCloseOperation. Algo como setDefaultCloseAction, que recebesse um enum.
O código interno das classes começa a ter que fazer malabarismos para suportar o antigo e o novo e, por consequencia, fica mais complexo e sujeito a erros.
[/quote]
Sim, vejo esse como o maior problema.
Em alguns casos você pode criar uma classe diferente com a melhor abordagem e depreciar a classe antiga toda.
Mas geralmente, o custo de manter a compatibilidade são esses malabarismos mesmo.
Tive uma experiência com uma lib de terceiros há pouco tempo atrás, que usou uma política semelhante e acabou me dando um nó.
Meu projeto utilizava as libs A e B. Ambas dependiam da C que eu não usava diretamente, tudo sem problemas.
Quando precisei atualizar A, notei que precisava atualizar C também.
Mas não existia versão de B que suportasse a última versão de C (que A precisava).
Se C tivesse mantido a mesma interface dos métodos acho que nem teria dado problema.
O problema é que justamente na última versão de C eles arrancaram os métodos @Deprecated.
Acho que se o Java incorporasse algum mecanismo pra carregar múltiplas versões de um jar, por exemplo, a quebra não seria um problema tão grande.