Najpierw pytanie, historia będzie następująca:

Czy mieszanie różnych wersji kodu bajtowego w hierarchii klas jest bezpieczne? Jakie są zagrożenia?

Dla przypadku klasa C rozszerza B, klasa B rozszerza klasę A. Klasa A implementuje interfejs I. Moje pytanie obejmowałoby następujące przykładowe scenariusze:

Klasa A skompilowana do kodu bajtowego Java 1.6 i ma funkcje 1.6, takie jak generics itp. Spadkobiercy, których są B i C, zostały skompilowane do kodu bajtowego 1.4.Interfejs skompilowałem do 1.6, podczas gdy implementor skompilował do 1.4.Inny scenariusz dziedziczenia egzotycznego obejmujący inną wersję kodu bajtowego.

Wypróbowałem tyle scenariuszy, ile mogłem sobie wyobrazić i wygląda na to, że działa dobrze. Jednak wciąż mam ochotę zapytać tutaj, ponieważ znam tylko Javę na powierzchni; Wiem, jak kodować i dostosowywać Javę, ale tak naprawdę nie wiem, co się dzieje pod maską.

Teraz dla tych umysłów, które nie mogą sobie pomóc zapytać „dlaczego miałbyś to zrobić ???”.

Jestem w projekcie oceny migracji starszej aplikacji Java 1.4 Swing, połączonej z EJB 2 przez RMI, do Java 1.6 Swing połączonego z nowszą wersją App Server działającą również na 1.6. Platforma J2EE nadal będzie miała 1.4 (EJB 2).

Migracja nie będzie „rekompilować wszystkiego do 1.6”, ale będzie „kodem i kompilacją nowych funkcji do 1.6”. Sposób, w jaki to robią, wygląda następująco: mają tylko jedną ścieżkę w CVS, wszyscy tam się angażują. Brak tagów / oddziałów w celu uzyskania kodu produkcyjnego. Za każdym razem, gdy trzeba dodać nową funkcję, pobierają pliki JAR z serwera produkcyjnego, rozbijają je, zastępują lub dodają nowe klasy według potrzeb, przepakowują słoiki, umieszczają je z powrotem na serwerze. Dlatego, jeśli będą używać Java 6 do kompilacji i użycia powyższej metody do wdrożenia, pojawi się wiele egzotycznych miksów kodu 1,4 i 1,6.