Краткий ответ

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

Методы, напротив, могут наследоваться, переопределяться и выбираться полиморфно во время выполнения.

Исторический контекст

В объектной модели Java конструктор отделён от обычного поведения объекта: его задача — привести новый экземпляр класса в корректное начальное состояние. Наследование предназначено для повторного использования поведения, тогда как состояние каждого класса должно инициализироваться по правилам этого класса.

Поэтому Java не рассматривает конструктор как обычный метод. Это позволяет подклассу самостоятельно определить способ создания собственного состояния, сохраняя обязательную инициализацию части объекта, принадлежащей суперклассу.

Постановка проблемы

Если бы конструкторы наследовались как методы, конструктор родителя мог бы создать объект подкласса, не зная о его дополнительных полях и инвариантах. Кроме того, у подкласса могли бы появиться неподходящие способы создания объекта или некорректно инициализироваться добавленные компоненты.

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

Подробное решение

У каждого класса есть собственные конструкторы. Они не участвуют в переопределении, не вызываются через ссылку на объект и не выбираются динамически по фактическому типу объекта.

При создании экземпляра сначала должен быть вызван конструктор суперкласса, затем выполняется инициализация полей и тело конструктора подкласса. Если первая инструкция конструктора не содержит явного вызова this(...) или super(...), компилятор добавляет вызов super() автоматически.

Автоматический вызов возможен только при наличии доступного конструктора суперкласса без параметров. Если такого конструктора нет, подкласс должен вызвать подходящий конструктор через super(...) явно. Вызов this(...) направляет выполнение в другой конструктор того же класса, а тот в конечном счёте также должен вызвать конструктор суперкласса.

Конструкторы можно перегружать, то есть объявлять несколько конструкторов с разными списками параметров. Но их нельзя переопределить, сделать static, final или abstract: эти свойства относятся к методам и не применяются к конструкторам.

Минимальный пример:

class Account {
    private final String id;

    Account(String id) {
        this.id = id;
    }
}

class PremiumAccount extends Account {
    PremiumAccount(String id) {
        super(id);
    }
}

class Demo {
    public static void main(String[] args) {
        new PremiumAccount("premium-1");
    }
}

У PremiumAccount нет унаследованного конструктора Account(String). Его конструктор самостоятельно вызывает super(id), чтобы инициализировать часть объекта, определённую в Account.

Ситуация из практики

Допустим, базовый класс подключается к внешнему ресурсу только после получения обязательного идентификатора, а подкласс добавляет настройки кэширования. Вариант с конструктором без аргументов опасен: он может оставить базовое состояние неинициализированным или привести к временному некорректному объекту.

Можно было бы добавить в базовый класс публичный конструктор без аргументов. Плюс этого решения — простое создание подклассов; минус — обязательные данные перестают проверяться на этапе создания, а объект может оказаться неполностью настроенным.

Более надёжный вариант — оставить обязательный конструктор базового класса и явно вызвать его из конструктора подкласса. Такой подход заставляет компилятор проверить цепочку инициализации и сохраняет инварианты базового класса. В результате объект создаётся только после инициализации обеих частей его состояния.

Что кандидаты часто упускают

Что произойдёт, если у суперкласса нет конструктора без параметров?

Неявный вызов super() станет невозможен, поэтому компиляция подкласса завершится ошибкой. Нужно явно вызвать доступный конструктор суперкласса через super(...). Если подходящего конструктора нет из-за его модификатора доступа или несовместимых параметров, подкласс создать нельзя, пока API суперкласса не изменится.
Можно ли считать конструкторы переопределяемыми при создании объекта через ссылку суперкласса?

Нет. Вызов конструктора определяется типом создаваемого класса и выбранным списком аргументов на этапе компиляции. Полиморфный выбор, характерный для переопределённых экземплярных методов, к конструкторам не применяется.
Можно ли одновременно вызвать this(...) и super(...) в одном конструкторе?

Нет. Явный вызов другого конструктора должен быть первой инструкцией, поэтому в одном конструкторе можно выбрать только одно направление: this(...) для делегирования конструктору того же класса или super(...) для вызова конструктора суперкласса. Цепочка через this(...) в итоге обязана завершиться вызовом super(...).