Все символические ссылки, которые теперь были загружены в область метода в форме пула констант времени выполнения, преобразуются в фактические типы, загруженные этой JVM.Если символьная ссылка может быть разрешена, но приводит к конфликту определений, выдается IncompatibleClassChangeError
.Если ссылочный класс не может быть найден, выдается NoClassDefFoundError
, который в основном оборачивает ClassNotFoundException
, который был сгенерирован загрузчиком классов, пытающимся загрузить этот ссылочный класс.Если ссылочный класс ссылается на себя, выдается ClassCircularityError
.Разрешение может происходить в одном из двух вариантов, который зависит от разработчиков JVM
Eager : все символические ссылки на другие поля, методы или классы разрешаются прямо сейчас.
Ленивый : Разрешение символьных ссылок откладывается до первого использования метода.Это может привести к тому, что класс, ссылающийся на несуществующий класс, никогда не выдаст ошибку, если эту ссылку не нужно разрешать.
Посмотрите на начало Глава 5.4.3. Резолюция, там указано явно:
Виртуальная машина Java инструктирует anewarray, checkcast, getfield, getstatic, instanceof, invokedynamic, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, multianewarray, new, putfieldи puttatic делают символические ссылки на пул констант во время выполнения.Выполнение любой из этих инструкций требует разрешения ее символьной ссылки.
Существует разрешение прямого суперкласса и непосредственно реализованных интерфейсов (или суперинтерфейсов в случае интерфейса), которое происходит рано, и естьразрешение символьных ссылок для приведенных выше инструкций байтового кода, которые могут быть отложены.