Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading Minecraft libraries on the BOOT layer is overly restrictive #131

Open
SquidDev opened this issue Aug 29, 2024 · 0 comments
Open

Comments

@SquidDev
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant