ООП и система типов

Как компилятор учитывает в функциональном интерфейсе абстрактный метод с сигнатурой публичного метода Object?

Какой набор проверяемых исключений может объявить реализация метода, совпадающего с методами двух интерфейсов с разными throws-клаузами?

Допустимо ли переопределить обобщённый метод базового класса, заменив его параметр типа на конкретный тип?

При рефлексивном поиске метода в иерархии классов чем отличается использование getDeclaredMethod от getMethod?

Сохраняется ли модификатор synchronized при переопределении экземплярного метода в классе-наследнике?

Вызов перегруженного метода получает лямбда-выражение без явного типа: что определяет, какая перегрузка будет выбрана?

Какие последствия для уже скомпилированного класса имеет добавление default-метода в реализуемый им интерфейс?

Сравните причину, по которой Java разрешает классу реализовывать несколько интерфейсов, но запрещает наследоваться от нескольких классов.

В сервисе метод принимает массив Object, а ему передают массив String; объясните, почему это разрешает компилятор, но запись числа может завершиться исключением.

Предскажите поведение уже скомпилированного класса, реализующего интерфейс, в который позже добавили абстрактный метод.

Почему Java запрещает объявлять перегрузки, различающиеся только параметрами обобщённого типа, например списком строк и списком чисел?

Какие требования к модификатору прямого наследника sealed-класса предотвращают появление неучтённых ветвей наследования?

Допустим, объект фактически создан как экземпляр класса, но сохранён в переменной интерфейсного типа: доступен ли через такую переменную публичный метод, которого нет в интерфейсе?

В проекте объявили sealed-класс: что именно ограничивает список его прямых наследников?

Что позволяет ссылке интерфейсного типа вызывать методы Object, которых интерфейс явно не объявляет?

Разберите результат вызова статического метода через null-ссылку: будет ли исключение и какой метод выбирается?

class Logger {
    static void ping() {
        System.out.println("ping");
    }
}

public class Demo {
    public static void main(String[] args) {
        Logger logger = null;
        logger.ping();
    }
}

В следующем коде объясните, почему вызов A.super.m() не компилируется, хотя B наследует метод от A:

interface A {
    default void m() {
        System.out.println("A");
    }
}

interface B extends A {
}

class C implements B {
    void call() {
        A.super.m();
    }
}

В перегруженном API обычный метод применим напрямую, а другой кандидат требует преобразования varargs: какой кандидат выберет Java и почему?

Что произойдёт, если подкласс объявит экземплярный метод с той же сигнатурой, что статический метод суперкласса?

Разберите, почему объявление C не компилируется, хотя в нём есть метод с совпадающими именем и параметрами:

interface A {
    Number value();
}

interface B {
    String value();
}

class C implements A, B {
    public String value() {
        return "ok";
    }
}