Fabric Loader is Fabric's lightweight mod loader. It provides the necessary tools to make Minecraft modifiable without depending on a specific version of the game. Game specific hooks belong in Fabric API.

It is in fact possible to adapt Fabric Loader for many Java applications.

A mod is a jar containing a fabric.mod.json mod metadata file declaring how it should be loaded. Among other things, this declares entrypoints and mixin configurations. The mod ID identifies the mod so that any mod with the same ID is considered to be the same mod. Only one version of a mod may be loaded at a time. A mod may declare other mods that it depends on or conflicts with. Fabric Loader will attempt to satisfy dependencies and load the appropriate versions of mods, or fail to launch otherwise.

Mods are loaded both from the classpath and from the mods directory. They are expected to match the mappings in the current environment, meaning Fabric Loader will not remap any mods.

Fabric Loader makes all mods equally capable of modifying the game. As an example, anything Fabric API does can be done by any other mod.

A mod may bundle a number of other mods within its jar. Nested jars must be declared by their paths relative to the containing jar's root. A nested jar must itself also be a mod, which again can have nested jars. Fabric Loader will load nested jars while attempting to satisfy dependency constraints.

Nested jars allow a mod to provide its own dependencies, so Fabric Loader can pick the best version matching the dependencies instead of requiring separate installation of dependencies. They also allow clean packaging of submodules, so each module can be used separately. Non-mod libraries can be repackaged as mods for nested jar usage.

See the guidelines for how to use nested jars effectively.

An entrypoint associates a code object conforming to some type with some event. The code object could be a class, a field or a method and is loaded by a language adapter. The language adapter will attempt to produce a Java object of a provided type using the code object.

An entrypoints is not loaded until it is fetched, and it can support various language loading schemes. This makes an entrypoint an excellent tool for optional mod integrations. A mod may support a specific entrypoint type by specifying a name and a type that another mod could provide an entrypoint for.

Fabric Loader has three built-in entrypoint types for mod initialization in relation to physical sides (see side). These endpoints are typically used to bootstrap mods by registering registry objects, event listeners and other callbacks.

• main: The first entrypoint to run. Expects the type ModInitializer.
• client: Will run after main only in a physical client. Expects the type ClientModInitializer.
• server: Will run after main only in a physical server. Expects the type ServerModInitializer.

The default language adapter supports the following types of code objects:

• Class: net.fabricmc.example.ExampleMod refers to the class by this name. The class must have a public constructor without arguments. The class must implement or extend the expected type. The return value is an instance of the class.
• Method: net.fabricmc.example.ExampleMod::method refers to a public method in that class by the name 'method'. If the method is nonstatic, an instance of the class is constructed for the method to be called on, meaning the class must also have a public constructor without arguments. Methods can only be used for interface types. The method must take the same arguments and have the same return type as the abstract method(s) in the interface. The return value is a proxy implementation of the interface, which will implement abstract methods by delegating to the method.
• Field: net.fabricmc.example.ExampleMod::field refers to the field in that class by the name 'field'. The field must be static and public. The value of the field must be an instance of the expected type or null. The return value is the value of the field.

References to methods and fields must be unambiguous. In case of ambiguity, no object is returned.

Mixin allows mods to transform Minecraft classes and even mod classes, and is the only method of class transformation that Fabric Loader allows. A mod can declare its own mixin configuration which enables the use of Mixin. Fabric Loader uses a slightly modified version of Mixin, but the documentation of the unmodified version is still mostly valid. The modifications are mostly related to making it work without LaunchWrapper.

When launched in a non-development environment, Fabric Loader will remap the Minecraft jar to intermediary names. Mods are expected to be mapped to intermediary, which will be compatible with this environment. This remapped jar is cached and re-used.

Fabric Loader uses a custom class loader to transform some classes at runtime. Classes belonging to a mod or Minecraft are loaded with a class loader that applies transformations to classes before they are loaded. Other classes, those belonging to other libraries, are delegated to the default classloader for isolation and performance.

Fabric Loader will perform side stripping on mod classes and Minecraft classes depending on the physical side that is launched. This involves completely removing classes, methods and fields annotated with @Environment annotations where the environment does not match. It also involves removing interface implementations on classes annotated with @EnvironmentInterface where the environment does not match. For Minecraft classes, this is used to simulate which classes and members that are available in the environment.

Package access hacks might be applied to Minecraft classes depending on the mappings in the current environment. With official (obfuscated) names and intermediary names, most classes are placed in the same package. However, Yarn mappings place classes in various packages which sometimes creates illegal access violations due to the access rules of protected and package-private members. Therefore, in a development environment where such access issues are known to exist, Minecraft classes are transformed so that package-private and protected members are made public. Outside a development environment we know that the package structure is flat, so the package access hack is not needed.