La pregunta primero, la historia seguirá:

¿Es seguro mezclar diferentes versiones de código de bytes en una jerarquía de clases? ¿Cuáles son los riesgos?

Para un caso, la clase C se extiende B, la clase B extiende la clase A. La clase A implementa la Interfaz I. Mi pregunta involucraría los siguientes escenarios de ejemplo:

La clase A se compiló a Java 1.6 bytecode y tiene 1.6 características tales como genéricos, etc. Los herederos, que son B y C, se compilaron a 1.4 bytecode.Interfaz compilé a 1.6, mientras que el implementador compiló a 1.4.Otro escenario de herencia exótico que involucra diferentes versiones de bytecode.

He intentado tantos escenarios que podría imaginar y parece funcionar bien. Sin embargo, sigo sintiendo la necesidad de preguntar aquí, ya que solo conozco Java en la superficie; Sé cómo codificar y modificar Java, pero realmente no sé qué sucede bajo el capó.

Ahora, para aquellas mentes que no pueden ayudarse a sí mismas a preguntar "¿por qué necesitarías hacer eso?".

Estoy en un proyecto para evaluar la migración de la aplicación Java 1.4 Swing heredada, conectada a EJB 2 a través de RMI, a Java 1.6 Swing conectada a una versión más nueva de App Server que se ejecuta sobre 1.6 también. La plataforma J2EE seguirá siendo 1.4 (EJB 2).

La migración no será "recompilar todo a 1.6", sino que será "codificar y compilar nuevas características a 1.6". La forma en que hacen las cosas es así: solo tienen un camino en el CVS, todos se comprometen allí. No hay etiquetas / ramas de ningún tipo para obtener el código de producción. Cuando sea necesario agregar una nueva función, obtienen los JAR del servidor de producción, los explotan, reemplazan o agregan nuevas clases según sea necesario, vuelven a empaquetar los tarros y los devuelven al servidor. Por lo tanto, si usarán Java 6 para compilar y usar el método anterior para la implementación, habrá muchas mezclas exóticas de 1.4 y 1.6 bytecodes.