Вопрос в первую очередь, история будет следовать:

Безопасно ли смешивать разные версии байт-кода в иерархии классов? Каковы риски?

Для случая, класс C расширяет B, класс B расширяет класс A. Класс A реализует интерфейс I. Мой вопрос будет включать следующие примеры сценариев:

Class A compiled to Java 1.6 bytecode, and have 1.6 features such as generics, etc. The heirs, which are B and C was compiled to 1.4 bytecode. Interface I compiled to 1.6, while the implementor compiled to 1.4. Other exotic inheritance scenario involving different version of bytecode.

Я перепробовал столько сценариев, сколько мог представить, и, кажется, все работает отлично. Однако я все еще чувствую желание спросить здесь, поскольку я знаю только Java на поверхности; я знаю, как кодировать и настраивать Java, но на самом деле не знаю, что происходит под капотом.

Теперь для тех умов, которые не могут помочь себе спросить: «Зачем вам это нужно?».

Я участвую в проекте по оценке миграции устаревшего приложения Java 1.4 Swing, подключенного к EJB 2 через RMI, на Java 1.6 Swing, также подключенного к более новой версии сервера приложений, работающей поверх версии 1.6. Платформа J2EE все еще будет 1.4 (EJB 2).

Миграция не будет «перекомпилировать все в 1.6», но будет «кодировать и компилировать новые функции в 1.6». То, как они делают вещи, выглядит так: У них есть только один путь в CVS, каждый фиксирует там. Никаких тегов / веток, чтобы получить производственный код. Всякий раз, когда необходимо добавить новую функцию, они получают JAR-файлы с рабочего сервера, взрывают их, заменяют или добавляют новые классы по мере необходимости, перепаковывают файлы jar, возвращают их на сервер. Поэтому, если они будут использовать Java 6 для компиляции и использовать вышеуказанный метод для развертывания, будет много экзотических миксов из 1,4 и 1,6 байт-кодов.