Undefined Entrypoint Behaviour

[senseiwells]

The fabric inject api relies on undefined entrypoint behaviour.

The fabric mod initialisation method sets InjectFabric.INSTANCE, prior to this it is null.

@Override
public void onInitialize() {
    INSTANCE = this;
    
    LOGGER.info("Inject initialising");
}

The examples in the README state you should hook into inject as follows:

public class MyMod implements ModInitializer {
    @Override
    public void onInitialize() {
        InjectFabric.INSTANCE.registerInjector(new MyEpicHttpInjector());
    }
}

However the order in which mods are initialised is undefined and thus this can result in mods crashing with NullPointerExceptions as InjectFabric.INSTANCE may or may not be initialised yet.

A simple solution would to just have a separate instance which is statically initialised, which would guarantee that the instance is always not null.

public final static InjectFabric INSTANCE = new InjectFabric();

[radstevee]

I think the best way to resolve this would just be to add the inject mod as a dependency in the FMJ. However I am unsure if that works with Jar-in-Jar.

I've never used that feature but I'm just assuming it loads the dependencies first.

[senseiwells]

No, the dependencies in the FMJ are just metadata, they are used in order to crash gracefully if a dependency is missing, it does not change the way that mods load.

There is no way to deterministically change the order in which mods load (for reasons explained in the link in my initial comment). This loading behaviour should not be relied on.

Mods are intentionally randomly shuffled by the fabric loader in the development environment to ensure non-deterministic behaviour:

// shuffle mods in-dev to reduce the risk of false order reliance, apply late load requests

if (isDevelopmentEnvironment() && System.getProperty(SystemProperties.DEBUG_DISABLE_MOD_SHUFFLE) == null) {
    Collections.shuffle(modCandidates);
}

[radstevee]

Fixed in 2.2.2