что происходит в java jvm, выполняющем устаревший код, который был признан недействительным при изменении языка

Question

Предположим, у вас есть устаревший код Java, который не может быть скомпилирован современной версией Java. например,

public class ProviderUnavailableException extends Exception {

    private int cause;

    public int getCause(){
        return cause;
    }
    // rest of implementation
}

Во времена Java 1.3 этот код был действителен.

В Java 1.4 класс Throwable «переопределил» метод getCause (). Это выглядит так:

public Throwable getCause()

Теперь устаревший код недопустим (поскольку int не является подтипом Throwable), но не приводит к проблемам во время выполнения. Или это может произойти при некоторых обстоятельствах?

Правильно ли, что во время компиляции компилятор сгенерировал байтовый код для обработки выполнения метода getCause исключительно в этом классе и поэтому «знает», что суперкласс не должен вызываться?

EDIT

Я проверил байт-код устаревшего кода с помощью «javap -c».

  public int getCause();
    Code: 
     0: aload_0
     1: getfield #2; //Field _cause:I
     4: ireturn 

Так что это возвращает локальное поле. Кажется, хорошо для меня.

Answer 1

В байт-коде метод упоминается по его имени, типам параметров и типу возвращаемого значения. Таким образом, два метода совершенно разные.

В байт-коде ваш метод 1.3 будет (я думаю):

getCause()J

В то время как новый метод 1.4:

getCause()Ljava/lang/Throwable;

Вы можете увидеть подписи, используя javap -s.

Ковариантные возвращаемые типы фактически реализуются во время компиляции javac с использованием методов синтетического моста. У них нет поддержки во время выполнения. Поэтому, если вы переопределите Object run() с помощью String run(), javac создаст оба метода в производном классе с Object run(), вызвав String run().

Answer 2

Во-первых, изменение подписи не является изменением языка. Обновление библиотек не является синтаксическим или функциональным изменением для языка Java. Ваш вопрос относится к тому, как поздняя среда выполнения связывает методы. Самый простой способ проверить это - смоделировать ту же проблему, используя ваши классы вместо ваших собственных.