A primeira pergunta, a história se seguirá:

É seguro misturar diferentes versões de código de bytes em uma hierarquia de classes? Quais são os riscos?

Para um caso, a Classe C estende B, a Classe B estende a Classe A. A Classe A implementa a Interface I. Minha pergunta envolveria os seguintes cenários de exemplo:

A classe A compilada para o bytecode do Java 1.6 e possui recursos 1.6, como genéricos, etc. Os herdeiros, que são B e C, foram compilados para o bytecode 1.4.Interface eu compilado para 1.6, enquanto o implementador compilado para 1.4.Outro cenário de herança exótica envolvendo diferentes versões do bytecode.

Eu tentei tantos cenários que eu poderia imaginar e parece correr muito bem. No entanto, ainda sinto o desejo de perguntar aqui, pois só conheço Java na superfície; Eu sei como codificar e ajustar Java, mas realmente não sei o que acontece sob o capô.

Agora, para aquelas mentes que não podem se ajudar a perguntar "por que você precisa fazer isso?".

Eu estou em um projeto para avaliar a migração do aplicativo Java 1.4 Swing herdado, conectado ao EJB 2 via RMI, para o Java 1.6 Swing conectado à versão mais recente do App Server em execução no topo da 1.6 também. A plataforma J2EE ainda será 1.4 (EJB 2).

A migração não será "recompilar tudo para 1.6", mas será "codificar e compilar novos recursos para 1.6". A maneira como eles fazem as coisas é assim: Eles só têm um caminho no CVS, todo mundo se compromete lá. Nenhuma tag / ramificação, seja qual for, para obter o código de produção. Sempre que um novo recurso precisar ser adicionado, ele obtém os JARs do servidor de produção, explode-os, substitui ou adiciona novas classes conforme necessário, reempacota os jars, coloca-os de volta ao servidor. Portanto, se eles usarem o Java 6 para compilar e usar o método acima para implantação, haverá muitas misturas exóticas de bytecodes de 1,4 e 1,6.