Абстрактный класс как функциональный интерфейс

В java 8 абстрактный класс с одним абстрактным методом не является функциональным интерфейсом (JSR 335).

Этот interface является функциональным интерфейсом:

public interface MyFunctionalInterface {
    public abstract void myAbstractMethod();
    public default void method() {
        myAbstractMethod();
    }
}

но это abstract class не является:

public abstract class MyFunctionalAbstractClass {
    public abstract void myAbstractMethod();
    public void method() {
        myAbstractMethod();
    }
}

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

public class Lambdas {
    public static void main(String[] args) {
        MyFunctionalAbstractClass functionalAbstractClass = () -> {};
    }
}

Ошибка компиляции: The target type of this expression must be a functional interface.

Почему разработчики языка наложили это ограничение?

Ответ 1

Это была важная тема с самого начала проекта Лямбда и получила много размышлений. Брайан Гетц (Brian Goetz), главный архитектор Java Java, сильно поддерживает представление лямбда как функции, а не объекта. Цитата:

Я считаю, что наилучшим направлением развития Java является поощрять более функциональный стиль программирования. Роль Лямбды прежде всего для поддержки развития и потребления функционально-подобные библиотеки

Я с оптимизмом смотрю на будущее Java, но, чтобы двигаться вперед, мы иногда должны отпустить некоторые удобные идеи. Открываются функции Lambdas-are двери. Объекты Lambdas-objects закрывают их. Мы предпочитаем видеть эти двери слева открыта.

Здесь есть ссылка на источник цитаты и здесь - это недавнее сообщение Брайана, которое повторяет то же самое философских точек и подтверждает их дополнительными, более практическими аргументами:

Создание модели проще открывает двери для всех видов ВМ оптимизаций. (Идентификация Jettisoning является ключевым здесь.) Функции значения. Моделирование их как объектов делает их более тяжелыми и сложными, чем они должны быть.

Перед тем, как бросить этот вариант использования в автобусе, мы сделали несколько корпусных анализов чтобы определить, как часто используются абстрактные SAM-классы по сравнению с интерфейсом ЗУР. Мы обнаружили, что в этом корпусе только 3% кандидата лямбды внутренние экземпляры классов имели абстрактные классы в качестве своей цели. И большинство они были поддаются простым рефакторингам, где вы добавили конструктор / factory, который принял лямбду, которая была ориентирована на интерфейс.