Teve uma bizarrice que eu fiz e acabei descobrindo ser um undefined behavior do Java.
Eu queria criar uma tela (em Swing mesmo), cujo layout estivesse previamente definido. Então, fiz o layout, com botões e tudo mais. E chamei um painel, que seria definido na subclasse. Nada mais do que isso aqui:
add(criarPainelCentral());
Então, imaginem. Bastaria o cara criar uma subclasse “TelaCadastro”, filha de “TelaAbstrata”, implementar o método criarPainelCentral() e já ganharia parte do layout.
Nenhum problema, certo? Errado.
O problema é que esse add estava no construtor. E, como vcs sabem, classes são criadas de cima para baixo. Então, no momento em que criarPainelCentral() era chamado, por ser um método sobrescrito, ele chamava um método de uma classe que ainda não existia.
A JVM da Oracle se comporta de uma maneira um tanto bizarra nesse caso:
a) Ela chama o construtor da superclasse;
b) Ao chegar no método virtual, ele vai para a subclasse.
c) Ele cria todos os atributos que forem usados da subclasse, no momento em que forem chamados;
d) No final do método, ele termina de rodar o construtor da superclasse;
e) E aqui vem a pegadinha. Ao terminar o construtor da superclasse, ele roda o da subclasse recriando todos os atributos.
Ou seja, eu acabava com uma tela cujos componentes do painel central eram exibidos, mas não eram os mesmos componentes que estava nas propriedades da classe. 
Levei trezentos e oito anos para descobrir porque diabos os componentes ignoravam os comandos que eram dados a eles nesse painel central.
Resolvemos o problema trocando de herança para composição. A tela com os botões passou a receber o painel por parâmetro em seu construtor. 