Точки входа объявляются в fabric.mod.json мода, чтобы предоставить части кода для использования загрузчиком Fabric или другими модами. В основном они используются для выполнения некоторого кода во время инициализации игры для инициализации модов, хотя система точек входа имеет и другие применения. Точки входа загружаются языковыми адаптерами, которые попытаются создать объект Java указанного типа, используя имя объекта кода.

Точка входа отображается под некоторым именем, ссылается на некоторый объект кода и должна основываться на знакомом прототипе точки входа. Прототип точки входа определяет имя (например, “main” или “client”) и ожидаемый тип объекта, на который должна ссылаться точка входа (например, интерфейс ModInitializer). Поставщик прототипа точки входа объявляет прототип точки входа и отвечает за доступ к точкам входа, а также может указать, как они будут использоваться. Fabric Loader предоставляет некоторые встроенные прототипы точек входа, в то время как моды также могут предоставлять свои собственные.

Точки входа можно считать более мощной реализацией Java Service Provider Interfaces.

Мод может объявлять любое количество точек входа под разными именами в своем fabric.mod.json. “main” используется для инициализации частей мода, которые являются общими как для клиента Minecraft, так и для выделенного сервера, таких как записи регистрации. “client” используется для инициализации частей мода, которые зарезервированы только для клиентов, таких как регистрация объектов, связанных с рендерингом.

{
  [...]
  "entrypoints": {
    "main": [
      "net.fabricmc.ExampleMod"
    ],
    "client": [
      "net.fabricmc.ExampleClientMod"
    ]
  }
  [...]
}

Внимание: Рекомендуется использовать отдельные классы для основных, клиентских и серверных точек входа, чтобы избежать проблем с загрузкой классов. Рассмотрим случай, когда один и тот же класс используется как для основной, так и для клиентской точки входа. При запуске на выделенном сервере, даже если точка входа “client” никогда не загружается, класс, содержащий логику инициализации клиента, будет. Даже если клиентская логика никогда не будет выполнена, простая загрузка кода может вызвать проблемы с загрузкой класса.

Fabric Loader предоставляет четыре встроенных прототипа точки входа для инициализации мода, некоторые из которых предназначены для работы с инициализацией по отношению к физическим сторонам (см. Серверная и Клиентские стороны). Основные, клиентские и серверные точки входа загружаются и вызываются на ранней стадии инициализации игры, в момент, когда большинство, но не все игровые системы готовы к модификации. Эти точки входа обычно используются для начальной загрузки модов путем регистрации объектов реестра, прослушивателей событий и других обратных вызовов для выполнения последующих действий.

• main: Первая обычная точка входа инициализации для запуска. Использует тип ModInitializer и вызывает onInitialize.
• client: Будет выполняться после main только в физическом клиенте. Использует тип ClientModInitializer и вызывает onInitializeClient.
• server: Будет выполняться после main только на физическом сервере. Использует тип DedicatedServerModInitializer и вызывает onInitializeServer.
• preLaunch (не рекомендуется для общего использования): Самая ранняя возможная точка входа, которая вызывается непосредственно перед запуском игры. Используйте с осторожностью, чтобы не мешать инициализации игры. Использует тип PreLaunchEntryPoint и вызывает onPreLaunch.

Все основные точки входа вызываются перед всеми точками входа клиента/сервера. Точное время вызова этих точек входа не указано и может варьироваться в разных версиях игры.

Ссылка на код точки входа преобразуется в экземпляр типа прототипа точки входа. Наиболее распространенный способ создания точки входа - это ссылка на класс, который реализует ожидаемый тип, но эти ссылки на код могут быть сделаны несколькими способами. Внутренне языковой адаптер отвечает за интерпретацию ссылок и превращение их в экземпляры. Языковой адаптер по умолчанию предназначен для кода Java и, таким образом, поддерживает следующие типы ссылок:

Будет переведено позже

• Ссылка на класс: ex. net.fabricmc.example.ExampleMod refers to the non-abstract class by this name. The class must have a public constructor with no arguments. The class must implement or extend the expected type. The resulting object is a new instance of the class.
• Ссылка на метод: ex. net.fabricmc.example.ExampleMod::method refers to a public method in that class by that name. If the method is nonstatic, a new instance of the class is constructed for the method to be called on, meaning the class must be non-abstract and also have a public constructor with no arguments. Methods can only be used for interface types. The method must accept the same arguments and have the same return type as the abstract method(s) in the interface. The resulting value is a proxy implementation of the interface, which will implement abstract methods by delegating to this method.
• Ссылка на статическое поле: ex. net.fabricmc.example.ExampleMod::field refers to the field in that class by that name. The field must be static and public. The the type of the field must be compatible with the expected type. The resuling value is the value of that field.

References to class members must be unambiguous, meaning the class must contain one and only one field or method with the targeted name. The language adapter cannot resolve methods overloads. In case of ambiguity, the entrypoint will fail to resolve.

Language adapters for other languages can be implemented by mods. fabric-language-kotlin provides a language adapter for Kotlin.

Mods can call each others' entrypoints for integration purposes. An entrypoint is loaded lazily when entrypoints for a specific entrypoint prototype are requested, which makes an entrypoint an excellent tool for optional mod integrations. A mod may become an entrypoint prototype provider by declaring that other mods should provide entrypoints based on an entrypoint prototype, often using a class or interface that the mod provides in its API. Mods can safely use this class or interface even if the provider is not installed (rendering the class or interface inaccessible) because entrypoints are loaded only on request. When the provider is not present, the entrypoint will simply be ignored.

Entrypoint instances can be accessed by calling FabricLoader#getEntrypointContainers(name, type). This returns a list of entrypoint containers. These containers contain the entrypoint instance and the mod container of the mod which provided the instance. This can be used by a mod to determine which mods have registered an entrypoint.

Entrypoint instances are memoized by their name and also their type. Using the same code reference for multiple entrypoints will result in multiple instances. Though highly absurd in practice, if getEntrypoints is called multiple times with the same name but different types, instances are constructed and memoized per type.

Fabric Loader does not have a concept of a load order or loading phases. Initializer entrypoints are the mechanism with which most mod loading is usually done, but whether or not an initializer has been called does not determine whether or not a mod can be considered to be “loaded”. Thus, it is unreasonable to expect that a mod has completed its modifications to the game after its initializers have been called. Additionally, the order in which entrypoints are called is mostly undefined and cannot be altered. The only guarantee is that a list of initializers in a fabric.mod.json file are called in the order in which they are declared. Fabric Loader does not provide multiple phases of initializers to work around the lack of order, either.

A common example is the expectation that mod A should be able to load after mod B because mod A will replace an object registered by mod B. Alternatively, mod C wants to be loaded before mod D because mod D will do something in response to a registration performed by mod C. This is cannot be done for two reasons:

1. Mod initializers are not required to represent a transition in a “mod loading lifecycle” so that after the initializer is called, all its registry objects are registered.
2. The order in which mod initializers are called is undefined, and cannot be influenced so that mod A's initializers are called after mod B's initializers, or so that mod C's initializers are called before mod D's initializers.

Leaving aside the missing guarantee of registration of all objects in initializers, one might argue that there should therefore be other entrypoints to perform “pre-initialization” and “post-initialization” so that there is a sense of order. This creates a multi-phase loading scheme, which in practice creates issues with the establishment of conventions for which operations are to be performed in which phase, uncertainty and lack of adherence to these conventions and outliers which do not fit.