Differences

This shows you the differences between two versions of the page.

--- documentation:entrypoint [2020/02/22 00:25] – [Basic usage] jamieswhiteshirt
+++ documentation:entrypoint [2023/06/10 12:04] – ↷ Links adapted because of a move operation mineblock11
@@ Line 1: / Line 1: @@
 ====== Entrypoints ======
-Entrypoints are declared in a mod's [[documentation:fabric_mod_json|fabric.mod.json]] to expose parts of the code for usage by Fabric Loader or other mods. They are primarily used to make some code run during game initialization to initialize mods, though the entrypoint system has other uses as well. Entrypoints are loaded by language adapters, which will attempt to produce a Java object of a specified type using the name of the code object.
+Entrypoints are declared in a mod's [[documentation:fabric_mod_json_spec|fabric.mod.json]] to expose parts of the code for usage by Fabric Loader or other mods. They are primarily used to make some code run during game initialization to initialize mods, though the entrypoint system has other uses as well. Entrypoints are loaded by language adapters, which will attempt to produce a Java object of a specified type using the name of the code object.
 An entrypoint is exposed under some name, refers to some code object and must be based on a familiar **entrypoint prototype**. An entrypoint prototype defines the name (such as "main" or "client") and the expected type of object that the entrypoint should refer to (such as the ''ModInitializer'' interface). An **entrypoint prototype provider** declares an entrypoint prototype and is responsible for accessing entrypoints, and can state how the they will be used. Fabric Loader provides some built-in entrypoint prototypes, while mods can also provide their own.
@@ Line 26: / Line 26: @@
 </code>
-**Caution:** It is recommended to use separate classes for main, client and server entrypoints to avoid class loading issues. Consider the case where the same class is used for both a main and a client entrypoint. When launched on a dedicated server, even if the "client" entrypoint is never loaded, the class that contains the client initialization logic will be. Even if the client logic will never be executed, the act of only loading the code may trigger class loading issues.
+**Caution:** It is recommended to use separate classes for main, client and server entrypoints to avoid class loading issues. Consider the case where the same class is used for both a main and a client entrypoint. When launched on a dedicated server, even if the "client" entrypoint is never loaded, the class that contains the client initialization logic will be. Even if the client logic will never be executed, the act of merely loading the code may trigger class loading issues.
 ==== Built-in entrypoint prototypes ====
@@ Line 55: / Line 55: @@
 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.
-Entrypoints can be accessed by calling ''FabricLoader#getEntrypoints(name, type)''. 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.
+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.
 ==== A note about load order and phases (or a lack thereof) ====