Для загрузки и создания класса или интерфейса C (не массива), обозначенного N, с помощью загрузчика начальной загрузки используются следующие шаги.

Сначала виртуальная машина Java определяет, был ли загрузчик начальной загрузки уже записан в качестве инициализирующего загрузчика класса или интерфейса, обозначенного N. Если да, то этот класс или интерфейс является C, и создание класса не требуется.

В противном случае виртуальная машина Java передает аргумент N вызову метода на загрузчике начальной загрузки для поиска предполагаемого представления C платформозависимым способом. Обычно класс или интерфейс будет представлен файлом в иерархической файловой системе, а имя класса или интерфейса будет закодировано в пути к файлу.

Обратите внимание, что нет гарантии, что найденное предполагаемое представление является действительным или является представлением C. Эта фаза загрузки должна обнаруживать следующие ошибки:

Затем виртуальная машина Java пытается вывести класс, обозначенный N, с помощью загрузчика начальной загрузки из предполагаемого представления, используя алгоритм, описанный в §5.3.5. Этот класс является C.

Следующие шаги используются для загрузки и, таким образом, создания не массивового класса или интерфейса C, обозначаемого N, с помощью пользовательского загрузчика классов L.

Сначала виртуальная машина Java определяет, был ли L уже записан как инициализирующий загрузчик класса или интерфейса, обозначаемого N. Если да, то этот класс или интерфейс — это C, и создание класса не требуется.

В противном случае виртуальная машина Java вызывает loadClass(N) для L. Возвращаемое значение вызова — созданный класс или интерфейс C. Затем виртуальная машина Java записывает, что L является инициализирующим загрузчиком C (§5.3.4). Остальная часть этого раздела описывает этот процесс более подробно.

Когда метод loadClass загрузчика классов L вызывается с именем N класса или интерфейса C, подлежащего загрузке, L должен выполнить одну из следующих двух операций, чтобы загрузить C:

В любом из случаев (1) или (2), если загрузчик классов L по какой-либо причине не может загрузить класс или интерфейс, обозначаемый N, он должен выбросить экземпляр ClassNotFoundException.

Начиная с версии JDK 1.1, реализация виртуальной машины Java от Oracle вызывает метод loadClass загрузчика классов, чтобы заставить его загрузить класс или интерфейс. Аргументом для loadClass является имя класса или интерфейса, который нужно загрузить. Существует также версия метода loadClass с двумя аргументами, где второй аргумент — boolean, указывающий, должен ли класс или интерфейс быть связан или нет. Только версия с двумя аргументами была предоставлена в версии JDK 1.0.2, и реализация виртуальной машины Java от Oracle полагалась на нее для связи загруженного класса или интерфейса. Начиная с версии JDK 1.1, реализация виртуальной машины Java от Oracle связывает класс или интерфейс напрямую, не полагаясь на загрузчик классов.

Следующие шаги используются для создания массива классов C, обозначаемого N, с помощью загрузчика классов L. Загрузчик классов L может быть либо загрузчиком базовых классов, либо пользовательским загрузчиком классов.

Если L уже был записан как инициализирующий загрузчик массива классов с тем же типом компонента, что и N, этот класс является C, и создание массива классов не требуется.

В противном случае для создания C выполняются следующие шаги:

Для обеспечения безопасной связи типов в присутствии загрузчиков классов необходимо соблюдать особую осторожность. Возможна ситуация, когда два разных загрузчика классов инициируют загрузку класса или интерфейса, обозначаемого N, при этом имя N может обозначать разные классы или интерфейсы в каждом загрузчике.

Когда класс или интерфейс C = <N1, L1> делает символическую ссылку на поле или метод другого класса или интерфейса D = <N2, L2>, символическая ссылка включает в себя дескриптор, определяющий тип поля или возвращаемые и аргументные типы метода. Важно, чтобы любое имя типа N, указанное в дескрипторе поля или метода, обозначало один и тот же класс или интерфейс при загрузке L1 и при загрузке L2.

Для обеспечения этого виртуальная машина Java накладывает ограничения загрузки в форме NL1 = NL2 во время подготовки (§5.4.2) и разрешения (§5.4.3). Чтобы применить эти ограничения, виртуальная машина Java в определенные моменты (см. §5.3.1, §5.3.2, §5.3.3 и §5.3.5), записывает, что определенный загрузчик является инициализирующим загрузчиком определенного класса. После записи того, что загрузчик является инициализирующим загрузчиком класса, виртуальная машина Java должна немедленно проверить, не нарушены ли какие-либо ограничения загрузки. Если это так, запись отменяется, виртуальная машина Java выводит LinkageError, и операция загрузки, которая привела к записи, завершается неудачей.

Аналогично, после наложения ограничения загрузки (см. §5.4.2, §5.4.3.2, §5.4.3.3 и §5.4.3.4), виртуальная машина Java должна немедленно проверить, не нарушены ли какие-либо ограничения загрузки. Если это так, недавно наложенное ограничение загрузки отменяется, виртуальная машина Java выбрасывает LinkageError, и операция, которая привела к наложению ограничения (либо разрешение, либо подготовка, в зависимости от случая), завершается неудачей.

Описанные здесь ситуации — единственные случаи, в которых виртуальная машина Java проверяет, нарушены ли какие-либо ограничения загрузки. Ограничение загрузки нарушается, если и только если выполняются все следующие четыре условия:

Полное обсуждение загрузчиков классов и безопасности типов выходит за рамки этой спецификации. Для более подробного обсуждения читателям рекомендуется обратиться к статье «Динамическая загрузка классов в виртуальной машине Java» Шенга Лянга и Гилада Брахи («Труды конференции ACM SIGPLAN 1998 по объектно-ориентированному программированию, системам, языкам и приложениям»).

Следующие шаги используются для вывода объекта Class для класса или интерфейса nonarray C, обозначенного N, используя загрузчик L из предполагаемого представления в формате файла class.

Виртуальная машина Java поддерживает организацию классов и интерфейсов в модули. Принадлежность класса или интерфейса C к модулю M используется для управления доступом к C из классов и интерфейсов в модулях, отличных от M (§5.4.4).

Принадлежность модулю определяется в терминах пакетов времени выполнения (§5.3). Программа определяет имена пакетов в каждом модуле и загрузчики классов, которые будут создавать классы и интерфейсы указанных пакетов; затем она указывает пакеты и загрузчики классов вызову метода defineModules класса ModuleLayer. Вызов defineModules заставляет виртуальную машину Java создавать новые модули времени выполнения, связанные с пакетами времени выполнения загрузчиков классов.

Каждый модуль времени выполнения указывает пакеты времени выполнения, которые он экспортирует, что влияет на доступ к public классам и интерфейсам в этих пакетах времени выполнения. Каждый модуль времени выполнения также указывает другие модули времени выполнения, которые он читает, что влияет на доступ собственного кода к public типам и интерфейсам в этих модулях времени выполнения.

Мы говорим, что класс находится в модуле времени выполнения, если пакет времени выполнения класса связан (или будет связан, если класс фактически создан) с этим модулем времени выполнения.

Класс, созданный загрузчиком классов, находится ровно в одном пакете времени выполнения и, следовательно, ровно в одном модуле времени выполнения, потому что виртуальная машина Java не поддерживает ассоциацию пакета времени выполнения с (или, более образно, "разделение по") несколькими модулями времени выполнения.

Модуль времени выполнения неявным образом связан ровно с одним загрузчиком классов в силу семантики defineModules. С другой стороны, загрузчик классов может создавать классы в более чем одном модуле времени выполнения, поскольку виртуальная машина Java не требует, чтобы все пакеты времени выполнения загрузчика классов были связаны с одним модулем времени выполнения.

Другими словами, отношение между загрузчиками классов и модулями времени выполнения необязательно является 1:1. Если для данной совокупности модулей, подлежащих загрузке, программа может определить, что имена пакетов в каждом модуле встречаются только в этом модуле, то программа может указать только один загрузчик классов для вызова defineModules. Этот загрузчик классов будет создавать классы по нескольким модулям времени выполнения.

Каждый модуль времени выполнения, созданный defineModules, является частью слоя. Слой представляет собой набор загрузчиков классов, которые совместно служат для создания классов в наборе модулей времени выполнения. Существуют два типа слоев: слой загрузки, поставляемый виртуальной машиной Java, и пользовательские слои. Слой загрузки создается при запуске виртуальной машины Java зависящим от реализации способом. Он связывает стандартный модуль времени выполнения java.base со стандартными пакетами времени выполнения, определенными загрузчиком базовых классов, такими как java.lang. Пользовательские слои создаются программами для построения наборов модулей времени выполнения, которые зависят от java.base и других стандартных модулей времени выполнения.

Модуль времени выполнения неявным образом является частью ровно одного слоя в силу семантики defineModules. Однако загрузчик классов может создавать классы в модулях времени выполнения разных слоев, поскольку один и тот же загрузчик классов может быть указан для нескольких вызовов defineModules. Управление доступом определяется модулем времени выполнения класса, а не загрузчиком класса, который создал класс, или слоем(ами), обслуживаемым загрузчиком.

Набор загрузчиков классов, указанных для слоя, и набор модулей времени выполнения, которые являются частью слоя, являются неизменными после создания слоя. Однако класс ModuleLayer предоставляет программам определенную степень динамического управления отношениями между модулями времени выполнения в пользовательском слое.

Если пользовательский слой содержит более одного загрузчика классов, то любая делегация между загрузчиками классов является обязанностью программы, создавшей слой. Виртуальная машина Java не проверяет, что загрузчики классов слоя делегируют друг другу в соответствии с тем, как модули времени выполнения слоя читают друг друга. Более того, если модули времени выполнения слоя изменены с помощью класса ModuleLayer для чтения дополнительных модулей времени выполнения, то виртуальная машина Java не проверяет, изменены ли загрузчики классов слоя каким-то внеполосным механизмом, чтобы делегировать соответствующим образом.

Существуют сходства и различия между загрузчиками классов и слоями. С одной стороны, слой похож на загрузчик классов тем, что каждый может делегировать, соответственно, одному или нескольким родительским слоям или загрузчикам классов, которые создали, соответственно, модули или классы ранее. То есть набор модулей, указанный слою, может зависеть от модулей, не указанных слою, а вместо этого указанных ранее одному или нескольким родительским слоям. С другой стороны, слой может использоваться для создания новых модулей только один раз, в то время как загрузчик классов может использоваться для создания новых классов или интерфейсов в любое время через несколько вызовов метода defineClass.

Возможно, что загрузчик классов определит класс или интерфейс в пакете времени выполнения, который не был связан с модулем времени выполнения ни одним из слоев, обслуживаемых загрузчиком. Это может произойти, если пакет времени выполнения воплощает имя пакета, которое не было указано для defineModules, или если класс или интерфейс имеет простое двоичное имя (§4.2.1) и, следовательно, является членом пакета времени выполнения, который воплощает безымянный пакет (JLS §7.4.2). В любом случае класс или интерфейс обрабатываются как член специального модуля времени выполнения, который неявно связан с загрузчиком классов. Этот специальный модуль времени выполнения известен как безымянный модуль загрузчика классов. Пакет времени выполнения класса или интерфейса связан с безымянным модулем загрузчика классов. Для безымянных модулей существуют специальные правила, призванные максимизировать их взаимодействие с другими модулями времени выполнения, как показано ниже:

Проверка (§4.10) гарантирует, что двоичное представление класса или интерфейса структурно верно (§4.9). Проверка может привести к загрузке дополнительных классов и интерфейсов (§5.3), но не обязательно к их проверке или подготовке.

Если двоичное представление класса или интерфейса не удовлетворяет статическим или структурным ограничениям, перечисленным в §4.9, то должна быть сгенерирована ошибка VerifyError в точке программы, которая вызвала проверку класса или интерфейса.

Если попытка Java Virtual Machine проверить класс или интерфейс завершается сгенерированной ошибкой, являющейся экземпляром LinkageError (или подкласса), то последующие попытки проверки класса или интерфейса всегда завершаются той же ошибкой, что и в результате первоначальной попытки проверки.

Подготовка включает создание статических полей для класса или интерфейса и инициализацию этих полей значениями по умолчанию (§2.3, §2.4). Это не требует выполнения кода Java Virtual Machine; явные инициализаторы статических полей выполняются как часть инициализации (§5.5), а не подготовки.

Во время подготовки класса или интерфейса C, Java Virtual Machine также накладывает ограничения на загрузку (§5.3.4):

Подготовка может происходить в любое время после создания, но должна быть завершена до инициализации.

Управление доступом применяется во время разрешения (§5.4.3) для обеспечения того, что ссылка на класс, интерфейс, поле или метод разрешена. Управление доступом успешно, если указанный класс, интерфейс, поле или метод доступен для ссылающегося класса или интерфейса.

Класс или интерфейс C доступен классу или интерфейсу D, если и только если выполняется одно из следующих условий:

Если C недоступен для D, управление доступом генерирует исключение IllegalAccessError. В противном случае управление доступом успешно.

Поле или метод R доступен классу или интерфейсу D, если и только если выполняется любое из следующих условий:

Если R недоступен для D, то:

В противном случае управление доступом успешно.

Гнездо — это набор классов и интерфейсов, которые позволяют взаимно обращаться к своим private членам. Один из классов или интерфейсов является хостом гнезда. Он перечисляет классы и интерфейсы, которые принадлежат к гнезду, используя атрибут NestMembers (§4.7.29). Каждый из них, в свою очередь, обозначает его как хост гнезда, используя атрибут NestHost (§4.7.28). Класс или интерфейс, у которого отсутствует атрибут NestHost, принадлежит гнезду, которое он сам размещает; если также у него отсутствует атрибут NestMembers, это гнездо является одиночным, состоящим только из самого класса или интерфейса.

Чтобы определить, принадлежит ли класс или интерфейс C тому же гнезду, что и класс или интерфейс D, применяется тест гнездования. C и D принадлежат одному гнезду, если и только если тест гнездования проходит успешно. Тест гнездования выполняется следующим образом:

Хост гнезда класса или интерфейса M определяется следующим образом:

Метод экземпляра mC может переопределить другой метод экземпляра mA, если выполняются все следующие условия:

public class A           {        void m() {} }
public class B extends A { public void m() {} }
public class C extends B {        void m() {} }

public class D extends P.C { void m() {} }

Во время выполнения инструкции invokeinterface или invokevirtual метод выбирается относительно (i) типа объекта в стеке во время выполнения и (ii) метода, ранее разрешенного инструкцией. Правила выбора метода относительно класса или интерфейса C и метода mR следующие:

Хотя C обычно является классом, он может быть интерфейсом, когда эти правила применяются во время подготовки (§5.4.2).