ServiceLoader не может найти поставщиков, когда содержащий модуль не объявляет директиву provides ... with в своем дескрипторе module-info.java. Java Platform Module System (JPMS) по умолчанию обеспечивает жесткую инкапсуляцию, что мешает ServiceLoader (находящемуся в java.base) получать доступ к классам в пакетах, которые не экспортируются или не открыты. Директива provides выступает в роли контрактного утверждения, которое предоставляет ServiceLoader привилегированный рефлексивный доступ для инстанцирования указанного класса поставщика, обходя нормальные ограничения доступности пакета без необходимости экспортировать пакет для всех модулей.
Контекст: Унаследованная корпоративная CRM-система переносилась с Java 8 на Java 17. Цель состояла в том, чтобы модульно разделить монолитную архитектуру на отдельные домены: crm-core, crm-email и crm-api. Модуль crm-email содержал реализацию интерфейса NotificationService, определенного в crm-api.
После миграции приложение выдало ServiceConfigurationError во время начальной загрузки. Это произошло, несмотря на то, что класс EmailNotificationService был публичным и JAR-файлы присутствовали на модульном пути. Стек вызовов указал на то, что для типа сервиса не найдены поставщики, что привело к сбою инициализации подсистемы уведомлений.
Проблема: Команда разработки предполагала, что публичная видимость класса реализации является достаточной. Это отражало предположения эпохи classpath, где публичные классы были глобально видимыми. Однако JPMS предотвращает доступ ServiceLoader к классам в неэкспортированных пакетах других модулей. Модуль crm-email не экспортировал пакет com.crm.email.internal. Критически, в module-info.java отсутствовала директива provides com.crm.api.NotificationService with com.crm.email.internal.EmailNotificationService. В результате ServiceLoader не смог найти или инстанцировать поставщика, так как модульная система воспринимала реализацию как инкапсулированную внутреннюю деталь.
Рассмотренные решения:
Экспорт пакета: Добавление exports com.crm.email.internal; в дескриптор модуля crm-email. Этот подход был отклонен, потому что он бы раскрыл внутренние детали реализации всем другим модулям. Это нарушало инкапсуляцию и создавало жесткую связь, которую модульная система была задумана предотвратить.
Открытие пакета для рефлексии: Использование opens com.crm.email.internal; или конкретно opens com.crm.email.internal to java.base;. Хотя это позволяет рефлексивный доступ, это было признано чрезмерным и семантически неверным. Это сигнализирует о том, что пакет подвержен глубокой рефлексии в общем, а не конкретно предоставляет сервис через контролируемый механизм.
Использование директивы provides ... with: Добавление заявления provides com.crm.api.NotificationService with com.crm.email.internal.EmailNotificationService; в module-info.java. Это идиоматическое решение JPMS. Оно явно объявляет взаимосвязь сервиса и предоставляет ServiceLoader необходимые права доступа для инстанцирования класса, сохраняя строгую инкапсуляцию.
Выбранное решение: Команда выбрала третий вариант. Этот подход не потребовал изменений в самом коде реализации. Он сохранил внутреннюю видимость пакета и сделал зависимость от сервиса явной в метаданных модуля.
Результат: Приложение успешно загрузило EmailNotificationService во время выполнения. Модульная граница осталась неповрежденной, предотвращая другие модули от прямой инстанциации или зависимости от внутренних классов реализации. ServiceLoader смог правильно обнаружить и предоставить сервис через объявленный контракт.
Почему ServiceLoader требует, чтобы класс поставщика имел публичный конструктор без аргументов, и какое конкретное исключение возникает, если это ограничение нарушено?
ServiceLoader инстанцирует классы поставщиков через рефлексию, используя Class.getConstructor().newInstance(). Это строго требует наличия публичного конструктора без аргументов. Если этого конструктора нет, или если он не публичен, ServiceLoader выбрасывает ServiceConfigurationError. Эта ошибка обычно оборачивается вокруг NoSuchMethodException или IllegalAccessException во время обхода итератора. Кандидаты часто упускают из виду, что этот конструктор должен быть явно предоставлен, если определены другие конструкторы. Они также не замечают, что инстанциация происходит лениво, когда вызывается Iterator.next(), а не во время начального вызова ServiceLoader.load().
Как механизм ServiceLoader обрабатывает классы поставщиков, расположенные в unnamed модулях, когда интерфейс сервиса определен в именованном модуле?
Когда интерфейс сервиса находится в именованном модуле, но реализация находится в неименованном модуле (classpath), ServiceLoader все равно может находить поставщика. Неименованные модули неявно читают все именованные модули, и все именованные модули неявно читают неименованные модули. Однако класс поставщика все равно должен быть публичным с публичным конструктором без аргументов. Ошибочное представление состоит в том, что сильная инкапсуляция полностью предотвращает этот сценарий. На самом деле, неименованный модуль действует как слой совместимости. Поставщики в неименованных модулях не могут быть доступны кодом в именованных модулях, который явно не читает неименованный модуль. Это создает направленное ограничение доступности, которое кандидаты часто не учитывают.
Что отличает метод ServiceLoader.loadInstalled() от ServiceLoader.load() с точки зрения делегирования загрузчиков классов и видимости поставщиков?
ServiceLoader.loadInstalled() использует системный загрузчик классов (или загрузчик платформы в современных версиях JVM) для поиска поставщиков. Он ограничивает обнаружение установленными модулями расширений или модулями платформы. Он явно игнорирует поставщиков на модульном пути приложения или classpath. В отличие от этого, ServiceLoader.load() обычно использует загрузчик контекста потока или конкретный загрузчик классов. Это позволяет ему находить поставщики на уровне приложения. Кандидаты часто путают эти методы, что приводит к молчаливым сбоям, когда поставщики приложений не находят. Это происходит, потому что loadInstalled() был использован неправильно, ожидая, что он будет вести себя как стандартный метод загрузки, но с более широкой видимостью.