In ide, minecraft classes should be loaded with knot than java's default class loader

[liach]

See FabricMC/yarn#2057

(net.minecraft.world.gen.chunk.NoiseChunkGenerator and net.minecraft.world.gen.StructureWeightSampler are in unnamed module of loader 'app')

Afaik running in other circumstances, such as in gradle run task or in production all goes through fabric loader. This one doesn't and apparently causes some trouble as it bypasses loaders' access hacks.

[Chocohead]

Were this the case no Mixins would be able to apply to them either... which would be a far bigger problem. Given Knot is the context class loader before mods are even discovered it's a little difficult to completely avoid loading classes through it, could do with actual reproduction cases/code to work out what is happening for sure.

[liach]

Maybe knot cannot find the class on classpath and just delegates to parent for the class, and the parent doesn't have pre-loading transformation hooks? That is a possibility.

[Chocohead]

That would only happen if the Minecraft jar was split up into multiple jars, because Loader would only count the one with a net.minecraft.client.main.Main type class as being the complete game, which Fabric doesn't do. Knot must have at least some of the game jar as it has to put the entrypoints in to load mod initialisers in the first place, presuming it's getting that far of course. It would be heavily unlikely Mixin wouldn't notice classes it wanted were missing too were it only getting fragments.

[liach]

Hmm, how did those classes escape into app classloader then? app should be the system class loader per https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/ClassLoader.html#getSystemClassLoader()

[Chocohead]

That's why I suggested getting a reproduction case, you can artificially do it readily enough but the Yarn report appeared like it was accidental.

[liach]

Hmm, in my intellij idea IDE I can never run my mods (always only loader loaded, mods folder works normally), and I always use runClient gradle task. I've only encountered such access issues before when I tried to run data generator in gradle tasks without fabric loader/knot. Need someone who can test this to test.

[Chocohead]

If you're running without Loader you'll definitely get these issues as any access problems are fixed by it at runtime (seemingly to avoid mods compiling to depend on them from Modmuss's responses to #352). In such contexts though it's not really Loom's problem given it is only catering for the expected use case that you're using Loader.

[liach]

@OroArmor do you have the full stacktrace of that illegal access error?

[modmuss50]

If you want to run the data generator it has to go through loader/knot for a few reasons (AW's and mixins are 2), for now id recommend just calling the data generator from a client or a server mod.

Getting loader setup to run data gen should be easy enough, but it would need to have a fabric api module to go with it. And even then id still suggest just calling it after a server has booted up and close gracefully once compelete to ensure mods are correctaly loaded.

[liach]

the problem now is not data gen. it's this access problem (in wrong classloader) happening under loader in dev env as seen in original yarn issue

[modmuss50]

Then I need a way to reproduce it, or at the very least a full stacktrace to know how it was launched.

[OroArmor]

@OroArmor do you have the full stacktrace of that illegal access error?

No, it was someone else that encountered it. I just reported it

[liach]

We need that full stacktrace in order to find out how minecraft classes are loaded by the app classloader without knot sanitization. Can you help contacting?

[OroArmor]

Sure give me a bit

[modmuss50]

Not seen this for a while, please open a new issue if it still happens.