Add a entrypoint before Mixin/AW bootstrap?

[LogicFan]

I am thinking to add an entry point before mixin/aw bootstrap happens (i.e. immediately after loading happens), which can give more flexibility for the mod developer. I guess we can call it PreInitEntryPoint?

I also see some previous attempts, it would be perfect if someone can share some difficulties on this.

[sfPlayer1]

This makes it very easy to screw the loaded classes up by loading classes too soon, we need to first ensure that none of MC or its libs are on the class path before invoking any mod code early.

[LogicFan]

By looking at the code, the class file of the mod is loaded inside freeze function. I think we could just insert an entry point between freeze and loadAccessWideners. No other loader code will be touched.

And I think, similar to the pre-launch entry point, it should be the developer's responsibility to not call MC code at this stage.

[sfPlayer1]

pre-launch was specifically placed at the earliest time where everything is safe to class load and set up, only static initializers can cause a problem there. freeze doesn't load mod classes, the first[1] opportunity is pre-launch entry points. Fabric doesn't have a mod class like ML/FML, itt's all entry points + mixins + json data. I'd rather wait with the feature until it can be done properly, which should be soon since I'm focusing on Loader atm.

[1} Language adapters are an exception, but those are really special

[LogicFan]

Correct if I am wrong, but inside freeze() -> finishModLoading() -> FabricLauncherBase.getLauncher().propose(mod.getOriginUrl()), I think the mod jar is loaded into the java classpath. And between freeze() and invoking preLaunch only contains aw setup & mixin setup. I am confused about why an entry point between freeze and aw/mixin is more dangerous than preLaunchEntryPoint.

Could you explain it in more detail? Thank you.

[LogicFan]

My intention is to provide a set of API that can manipulate the mixin & aw bootstrap of the fabric loader from a mod, which should not be for general use. This entry point should only be used when it is absolutely necessary.

The use case for this would be:

1. adding the dependency dynamically from the mod.
2. implement another plugin system as a fabric mod that supports mixin/aw.

[sfPlayer1]

Adding the Jar to the class path does nothing since anything JVM is using lazy loading. Only when a class is accessed the first time, it'll be class loaded, load referenced classes call initializers and thus potentially break. Entry points are usually where such an access can happen initially, not the pure class path addition.

I definitely want to properly support these advanced uses, but not with the current fragile class loader setup and with some preparations for caching related state. Eventually the bulk of loader's activity is supposed to be cached until the mod set or other inputs change. Bytecode transformations are supposed to be applied in bulk on startup, then reused until mods or relevant configs change. I've been talking about these things for well over a year, just getting around to it now (see the PR/commit activity). I'll see about describing my ideas soon if you are interested.

[LogicFan]

I am definitely interested in your idea and would like to help if needed.

From what I understand from your reply, it seems that you want to apply aw/mixin first, then manipulate later as mod needed.

• However, this does not solve the dynamic dependency problem since the aw/mixin might involve a non-loaded class in this situation.
• Furthermore, some mod might want to actually interfere with the mixin bootstrap process, not only just adding a new mixin config. From what I understand, mixin cannot be bootstrap twice. This could also be an issue.

[sfPlayer1]

No, I said that the current setup doesn't lend itself to do anything earlier than pre-launch. Once the class loader setup is such that none of the problematic classes (mostly MC+libs) are loadable from the early-executed code, it'd be possible. Adding extra mods etc obviously need to be done quite early on.

[LogicFan]

I see. That makes sense. Thanks for your detailed explanation.

Have you started working on this feature? If not then I am happy to attempt to write it.

[sfPlayer1]

I'm working on other bits that somewhat influence it atm. I think the next step would be having a chat.

[Chocohead]

What would you be trying to do to Mixin before bootstrap in the first place? You can't (or at least shouldn't) even interact with it before the MixinBootstrap#init call so I don't understand why you'd want to be going earlier than preLaunch.

There is certainly merit in being able to add your own mods into the resolution process through Loader plugins, as has been discussed in #223 for example, but even the goal is to make Loader handle them like a mod loaded normally rather than something which needed special handling for Mixins, AWs, etc.

[LogicFan]

What would you be trying to do to Mixin before bootstrap in the first place?

The use case could be:

1. dynamic loads library required by IMixinConfigPlugin.
2. do some initialization needed or alter the function of IMixinConfigPlugin.
3. alter the aw file loaded by fabric loader.
4. re-order how fabric do mixin
5. etc.