Что произойдет, если я удалю вызов суперконструктора из файла класса?

Я попробовал это сам.

class Test
{
    public Test()
    {
        System.out.println("Hello World");
    }

    public static void main(String[] args)
    {
        new Test()
    }
}

Я скомпилировал его и удалил invokespecial java/lang/Object/<init>()V из конструктора с помощью редактора файлов классов.

Похоже, JVM отказывается загружать класс:

Exception in thread "main" java.lang.VerifyError: Operand stack overflow
Exception Details:
  Location:
    Test.<init>()V @4: ldc
  Reason:
    Exceeded max stack size.
  Current Frame:
    bci: @4
    flags: { flagThisUninit }
    locals: { uninitializedThis }
    stack: { uninitializedThis, 'java/io/PrintStream' }
  Bytecode:
    0000000: 2ab2 0002 1203 b600 04b1

        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
        at java.lang.Class.getMethod0(Unknown Source)
        at java.lang.Class.getMethod(Unknown Source)
        at sun.launcher.LauncherHelper.validateMainClass(Unknown Source)
        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

Я до сих пор не знаю, является ли это определенным поведением.

ИЗМЕНИТЬ

По словам Редвальда, я также должен изменить манипуляции со стеком.

Поэтому я также удалил aload_0, который был до вызова суперконструктора.

Теперь я получаю следующее исключение:

Exception in thread "main" java.lang.VerifyError: Constructor must call super()
or this() before return
    Exception Details:
  Location:
    org/exolin/geno/Test.<init>()V @8: return
  Reason:
    Error exists in the bytecode
  Bytecode:
    0000000: b200 0212 03b6 0004 b1

        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
        at java.lang.Class.getMethod0(Unknown Source)
        at java.lang.Class.getMethod(Unknown Source)
        at sun.launcher.LauncherHelper.validateMainClass(Unknown Source)
        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

Это вызвало у меня любопытство, поэтому я переупорядочил инструкции конструктора следующим образом:

getstatic java/lang/System/out Ljava/io/PrintStream;
ldc "Message"
invokevirtual java/io/PrintStream/println(Ljava/lang/String;)V
aload_0
invokespecial java/lang/Object/<init>()V
return

Который сработал!

Существует различие между тем, что требуется на уровне языка Java, и тем, что требуется на уровне байт-кода, что гораздо слабее.

На уровне языка Java вы должны иметь вызов конструктора в качестве первого оператора, но компилятор вставит его неявно, если вы его пропустите.

На уровне байт-кода единственным требованием является наличие ровно одного вызова конструктора на каждом пути кода, который возвращается нормально, плюс существуют ограничения на то, что вы можете делать со значением this до инициализации.

В частности, это означает, что

• Вызов конструктора не обязательно должен находиться в начале метода.
• Вы можете выбирать между вызовом разных конструкторов на основе условной логики.
• У вас могут быть обработчики исключений в конструкторе, включая перехват исключений, созданных конструктором суперкласса.
• У вас может вообще не быть вызовов конструктора, если каждый путь кода вызывает исключение или входит в бесконечный цикл.

Первый вариант фактически появляется в сгенерированном коде Javac, потому что в Java вы можете передать выражение в качестве аргумента вызову конструктора, и код для вычисления этого выражения, очевидно, должен произойти до вызова конструктора. Но остальные из этих опций невозможно выполнить в Java.

Обратите внимание, что если вы нарушите эти ограничения, что произойдет, если вы удалите вызов конструктора из обычного конструктора Java, который возвращается нормально, конструктор теперь будет недействительным, поскольку он возвращает, но не имеет вызова ctor. Таким образом, попытка загрузить класс во время выполнения завершится ошибкой VerifyError.

Для полноты вот что вы можете сделать с неинициализированным значением this: сравнить его с нулевым значением и сохранить (но не прочитать) поля, определенные в том же классе.

Не так много, верно? Но возможность сохранять поля, определенные в том же классе до вызова ctor, на самом деле используется компилятором Java. На уровне байт-кода нет понятия внутренних классов, поэтому, когда вы ссылаетесь на внешний класс во внутреннем классе, компилятор создает скрытое поле во внутреннем классе, содержащее ссылку на внешний класс. Чтобы убедиться, что это работает правильно, если конструктор суперкласса вызывает метод, который переопределен во внутреннем классе и который обращается к внешнему классу, это скрытое поле должно быть инициализировано до вызова конструктора суперкласса. Конечно, вы можете сделать с этим больше, когда сами пишете байт-код.

Последняя спецификация JVM говорит об этом в 4.9.2 Структурные ограничения:

"Каждый метод инициализации экземпляра, за исключением метода инициализации экземпляра, полученного из конструктора класса Object, ДОЛЖЕН вызывать либо другой метод инициализации экземпляра этого, либо метод инициализации экземпляра его прямого суперкласса, прежде чем будут доступны члены его экземпляра."

Другими словами, если вы удалите последовательность инструкций invokespecial <init>, соответствующую вызову конструктора super(...) или this(...), то файл класса станет недействительным, и средство проверки должно это обнаружить.

(И, согласно исследованиям @Jimmy T, так оно и есть!)

Причина этого ограничения объясняется другими ответами.