Какие последствия для уже скомпилированного класса имеет добавление default-метода в реализуемый им интерфейс?
Добавление default-метода обычно сохраняет бинарную совместимость: уже скомпилированный класс не обязан быть перекомпилирован и получает реализацию по умолчанию при последующем вызове этого метода. Если класс или его суперкласс уже содержит метод с подходящей сигнатурой, будет использована эта реализация, а не default-метод интерфейса.
Однако добавление default-метода может изменить поведение вызовов и создать конфликт с default-методами других интерфейсов. Поэтому бинарная совместимость не означает неизменность семантики программы.
До появления default-методов добавление нового абстрактного метода в публичный интерфейс ломало существующие реализации: класс, скомпилированный раньше, не содержал необходимого метода, а новый исходный код уже не мог корректно реализовать интерфейс без изменений.
В Java 8 default-методы позволили развивать интерфейсы, добавляя новую операцию вместе с базовой реализацией. Это решило проблему эволюции библиотек, но перенесло часть сложности в разрешение конфликтов и выбор реализации во время выполнения.
Предположим, библиотека выпускает новую версию интерфейса с default-методом, а приложение продолжает использовать старый, уже скомпилированный класс-реализацию. Важно определить, загрузится ли такой класс, какая реализация будет вызвана и не изменится ли поведение после обновления библиотеки.
Ошибочное предположение состоит в том, что default-метод всегда заменяет метод класса. На самом деле реализация класса или его суперкласса имеет приоритет, а default-метод используется только если подходящей реализации в иерархии классов нет.
При вызове метода через ссылку интерфейсного типа Java сначала разрешает сам член интерфейса, а затем выбирает наиболее конкретную допустимую реализацию объекта. Метод класса имеет приоритет над default-методом интерфейса. Поэтому добавленный default-метод не переопределяет существующий метод класса.
Если старый конкретный класс не имел метода, потому что прежняя версия интерфейса его вообще не объявляла, новый default-метод может стать доступной реализацией для экземпляров этого класса. Это и обеспечивает совместимость: класс не требуется изменять только из-за появления нового метода.
Если несколько интерфейсов предоставляют конфликтующие default-методы, одного добавления метода может оказаться недостаточно. При наличии наиболее специализированного интерфейса конфликт иногда разрешается автоматически; в неоднозначной ситуации класс должен явно переопределить метод. Для уже скомпилированных артефактов результат зависит от того, какие типы и методы были доступны при компиляции и какие классы загружены во время выполнения.
Добавление default-метода также может изменить результат вызова в существующем клиентском коде: ранее вызов мог завершаться ошибкой отсутствия реализации, а после обновления начать выполнять новую реализацию. Поэтому при изменении публичного интерфейса нужно проверять не только бинарную совместимость, но и поведенческие последствия.
Библиотека содержит интерфейс обработчика, а сторонние приложения реализуют его собственными классами. В новой версии библиотека добавляет в интерфейс необязательную операцию с default-реализацией, чтобы старые реализации не пришлось немедленно обновлять.
Вариант с добавлением абстрактного метода проще концептуально, но ломает старые реализации при перекомпиляции и может привести к ошибкам выполнения при несовместимом обновлении компонентов. Вариант с default-методом сохраняет совместимость, но требует проверить конфликты с уже существующими методами классов и другими интерфейсами.
Выбирают default-метод, потому что он позволяет старым классам продолжить работу, а новым реализациям при необходимости переопределить поведение. При этом в тестах отдельно проверяют класс с собственной реализацией, класс с реализацией в суперклассе и классы, реализующие несколько интерфейсов.
Обязательно ли перекомпилировать класс-реализацию после добавления default-метода?
Обычно нет: именно сохранение работоспособности ранее скомпилированных реализаций является одним из предназначений default-методов. При загрузке и вызове метода JVM может использовать новую default-реализацию интерфейса. Перекомпиляция всё же может выявить новые конфликты или изменить диагностируемые компилятором проблемы, поэтому совместимость на уровне байткода не исключает необходимости повторной сборки и тестирования.
Что произойдёт, если старый класс уже имеет метод с такой сигнатурой?
Будет использован метод класса, включая метод, унаследованный от суперкласса, если он подходит для вызова. Default-метод интерфейса не вытесняет реализацию класса, поскольку класс является более приоритетным источником реализации. Это может привести к тому, что после обновления интерфейса часть реализаций будет выполнять новый default-код, а часть — старый код суперкласса.
Может ли добавление default-метода вызвать конфликт, которого раньше не было?
Да. Если класс реализует несколько интерфейсов, и после обновления два из них начинают предоставлять несовместимые default-методы одной сигнатуры, у класса может не оказаться однозначной реализации. В таком случае конфликт нужно устранить явным переопределением в классе либо изменением иерархии интерфейсов; полагаться только на успешную загрузку старой версии нельзя.