Объясните, почему классы с одинаковым полным именем, загруженные двумя независимыми загрузчиками, считаются разными типами в JVM.
В JVM тип определяется не только полным именем класса, но и загрузчиком, который его определил. Поэтому два класса с именем com.example.Plugin, загруженные разными загрузчиками, несовместимы: JVM рассматривает их как разные типы, даже если байткод полностью совпадает.
Из-за этого приведение экземпляра одного класса к типу, загруженному другим загрузчиком, завершается ClassCastException или другой ошибкой проверки типов.
Такая модель нужна для одновременной поддержки повторного использования классов и изоляции компонентов. Приложение, сервер приложений или система плагинов могут загружать независимые версии библиотек, не смешивая их статическое состояние и зависимости.
Без связи между загрузчиком и идентичностью типа два несовместимых класса с одинаковым именем могли бы случайно считаться одним типом. Это нарушило бы типобезопасность и изоляцию компонентов.
Предположим, сервер загрузил API плагина одним загрузчиком, а сам плагин — дочерним загрузчиком. Если плагин принесёт собственную копию этого API, его реализация будет реализовывать не тот интерфейс, который видит сервер.
Внешне имена интерфейсов совпадают, но для JVM это разные типы. Попытка передать объект через границу компонентов может завершиться ошибкой приведения, а раздельные копии классов могут привести к неожиданно разному статическому состоянию и несовместимым версиям зависимостей.
Идентичность загруженного класса определяется парой: полное бинарное имя и определивший загрузчик. Поэтому A, определённый загрузчиком L1, и A, определённый загрузчиком L2, — разные типы, если L1 и L2 различаются.
Загрузчик сначала может делегировать поиск родителю. Это стандартная политика, но не неизменное правило JVM: пользовательский загрузчик способен реализовать, например, child-first-стратегию. При успешной загрузке конкретный загрузчик обычно кэширует результат для имени класса и повторно использует ту же определённую сущность.
Родительская делегация особенно важна для общих контрактов. Если интерфейс плагина загружен родительским загрузчиком, а реализация — дочерним, объект реализации может быть передан серверу как экземпляр этого интерфейса. Если же интерфейс загрузили отдельно оба загрузчика, граница типов разрывается.
Загрузчик влияет не только на проверку приведения. У копий класса будут независимые статические поля, синхронизация по классу и метаданные типа. Одинаковое имя ресурса также может разрешаться по-разному, поскольку загрузчик определяет область поиска.
Практическое правило: общие API и типы, пересекающие границу компонентов, должны загружаться из общего родительского слоя. Реализации и их изолированные зависимости можно оставлять в дочернем загрузчике. Нельзя исправить несовместимость простым переименованием переменной или приведением типа — нужно согласовать загрузчиков и границу видимости классов.
В сервере плагинов каждый модуль получил собственный загрузчик. Сервер передавал плагину объект общего интерфейса, но при обратном вызове получал ошибку приведения: интерфейс существовал и в сервере, и внутри JAR плагина.
Рассматривались три варианта. Полностью общий загрузчик упрощал обмен объектами, но устранял изоляцию версий. Политика child-first давала плагинам независимые зависимости, однако повышала риск дублирования API. Передача данных только через примитивы или сериализацию устраняла проблему типов, но увеличивала стоимость обмена и усложняла контракт.
Выбрали отдельные загрузчики с родительским общим API: сервер загружал интерфейсы и DTO, а загрузчик плагина — только реализацию и внутренние библиотеки. После удаления дублирующей копии API объекты начали успешно проходить через границу, а независимые версии внутренних зависимостей сохранили изоляцию.
Нет. Совпадение имени и содержимого байткода не заменяет совпадение определившего загрузчика. Это позволяет двум приложениям использовать разные версии класса с одним именем, но означает, что обмен экземплярами между такими областями невозможен без явного межкомпонентного протокола, например сериализации.
Проверка реализации интерфейса использует конкретный объект типа интерфейса. Если сервер видит PluginApi, определённый L1, а плагин реализует PluginApi, определённый L2, эти интерфейсы различны. Размещение API в родительском загрузчике гарантирует, что сервер и дочерние загрузчики используют одну определённую версию контракта.
Нет. Контекстный загрузчик влияет на то, где некоторые библиотеки ищут классы и ресурсы, но не меняет идентичность уже определённого типа. Однако если библиотека использует контекстный загрузчик для загрузки API или реализации, разные значения этого загрузчика могут привести к появлению двух классов с одинаковым именем и последующей несовместимости.