I'm fairly sure this is a "working as intended", so feel free to close. However, while I understand the intent behind the current behaviour, it was a little surprising, and so felt worth documenting.
One of the features of a mod I maintain is the ability to connect to connect to a websocket server and send/receive messages. We do this by jar-in-jaring various additional Netty libraries (e.g. io.netty:netty-codec-http).
However, base Netty does not natively support some of the mod advanced websocket compression options (such as non-default compression levels). To support this, Netty uses jzlib.
jzlib is not included with netty by default, so I need to supply it as an additional library. Unfortunately, there is no way to do this as a mod. The library which tries to use jzlib ( io.netty:netty-codec) is bundled as part of Minecraft, and so resides on the BOOT layer, which cannot be extended by any modlauncher mechanism.
My gut feeling here is there could be a stronger separation between libraries that the modlauncher/FML systems need (which could reside on the BOOT layer), and those which are only needed by Minecraft (and so could be loaded later on), but I'm not super familiar with all the nuances here, so may be missing something!
I'm fairly sure this is a "working as intended", so feel free to close. However, while I understand the intent behind the current behaviour, it was a little surprising, and so felt worth documenting.
One of the features of a mod I maintain is the ability to connect to connect to a websocket server and send/receive messages. We do this by jar-in-jaring various additional Netty libraries (e.g.
io.netty:netty-codec-http).However, base Netty does not natively support some of the mod advanced websocket compression options (such as non-default compression levels). To support this, Netty uses jzlib.
jzlib is not included with netty by default, so I need to supply it as an additional library. Unfortunately, there is no way to do this as a mod. The library which tries to use jzlib (
io.netty:netty-codec) is bundled as part of Minecraft, and so resides on theBOOTlayer, which cannot be extended by any modlauncher mechanism.My gut feeling here is there could be a stronger separation between libraries that the modlauncher/FML systems need (which could reside on the BOOT layer), and those which are only needed by Minecraft (and so could be loaded later on), but I'm not super familiar with all the nuances here, so may be missing something!