Nuke CHASM, Create a Rudimentary TransformCache API #484
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's not happening. Sorry. This is step 0 in making the Transform Cache available for transformer plugins (as opposed to `GameProvider`/game plugins and `QuiltLoaderPlugin`/solver plugins)
This commit creates a TransformCache API that resembles the solver plugin API. It currently is only used by the GameProvider. Mods can not yet register their own transformers. The idea behind this system is to make it so that there is no privileged transform system in Loader: a modder could use Mixin, or another lib like [sushi](https://github.com/CichlidMC/sushi/)--a sort of spiritual successor to CHASM--or hand-roll patches with the new ClassFile API, or whatever else. (this applies to using Loader for other games too!) It would also provide a convient way for plugins to cache transformations of mods they provide without needing to hand-roll their own system. Some things to note: - The egronomics for using the API is not great; see GameTransformerPlugin in the Minecraft game provider. It's not a goal to provide anything other than byte->byte transformation of files, but that doesn't mean the main API needs to be filesystem based. - There is a phase system copied directly from QSL, with the exception that cycles are an immediate crash. - The phases are sorted consistently, as long as the same transformers are registered they will run in the same order, regardless of mods loaded, load order, moon phase, etc. - I haven't figured out how I want the ergonomics of the default phases to work yet. That will probably be finalized once everything is on the cache, including cached mixin (fingers crossed!), and we let mods register plugins.
OroArmor
reviewed
Nov 21, 2025
Comment on lines
+40
to
+60
| interface ClassConsumer { | ||
| /** | ||
| * Consume a class and potentially transform it. | ||
| * | ||
| * @param mod the mod which "owns" this class file | ||
| * @param className the name of the class in dot form (e.g. {@code net.minecraft.client.MinecraftClient$1} | ||
| * @return the transformed bytes, or null if nothing was changed. Use {@link TransformCache#hideClass(String, String)} to delete a class. | ||
| */ | ||
| byte @Nullable [] run(ModLoadOption mod, String className, Path file) throws IOException; | ||
| } | ||
|
|
||
| @FunctionalInterface | ||
| interface ModClassConsumer { | ||
| /** | ||
| * Consume a class and potentially transform it. | ||
| * | ||
| * @param className the name of the class in dot form (e.g. {@code net.minecraft.client.MinecraftClient$1} | ||
| * @return the transformed bytes, or null if nothing was changed. Use {@link TransformCache#hideClass(String, String)} to delete a class. | ||
| */ | ||
| byte @Nullable [] run(String className, Path file) throws IOException; | ||
| } |
Member
There was a problem hiding this comment.
What's the difference between these two? Just a higher degree of specificity?
Contributor
Author
There was a problem hiding this comment.
if you are iterating over one mod you know what the load option is already, though I guess it might be worth leaving it to make using method references easier?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goodbye, CHASM.
I'm probably going to keep hacking on this for a while, but I never know when I'll have time, so if this seems like an improvement over the status quo I'd like to get it merged.
This commit creates a TransformCache API that resembles the solver
plugin API. It currently is only used by the GameProvider. Mods can
not yet register their own transformers.
The idea behind this system is to make it so that there is no
privileged transform system in Loader: a modder could use Mixin, or
another lib like sushi--a sort of
spiritual successor to CHASM--or hand-roll patches with the new
ClassFile API, or whatever else. (this applies to using Loader for
other games too!)
It would also provide a convenient way for plugins to cache transformations
of mods they provide without needing to hand-roll their own system.
Some things to note:
GameTransformerPlugin in the Minecraft game provider. It's not a goal
to provide anything other than byte->byte transformation of files, but
that doesn't mean the main API needs to be filesystem based.
that cycles are an immediate crash.
transformers are registered they will run in the same order,
regardless of mods loaded, load order, moon phase, etc.
phases to work yet. That will probably be finalized once everything
is on the cache, including cached mixin (fingers crossed!), and we
let mods register plugins.