All Classes and Interfaces
Class
Description
Applies Forge-style access-widening rules directly to loaded bytecode.
Parses Forge-style access-transformer files: one rule per line,
<access>[+f|-f] <owner> [<member> [<descriptor>]] # comment.One Forge-style access-transformer rule:
<access>[+f|-f] <owner> [<member> [<descriptor>]].Applies every mod's raw
AsmTransformer, in mod load order, to every loaded class.A mod's raw ASM entrypoint - for bytecode changes Mixin can't express (renaming members, adding
interfaces, complex control-flow rewrites).
Jars added to the runtime classpath after the JVM started (mod jars, appended via
Instrumentation.appendToSystemClassLoaderSearch) don't show up in the
java.class.path system property, which only reflects the original -cp.Attached automatically before the target's own
main() runs, via
the Launcher-Agent-Class manifest attribute JarPatcher
writes into the patched jar (or manually via -javaagent, hence
HloaderAgent.premain(String, Instrumentation)).Backs Mixin's "blackboard" with a simple in-memory map.
hloader's Mixin host service.
MixinServiceAbstract.getSideName() (client vs.Discovers mod jars, initializes their entrypoints, and runs their lifecycle.
It adds a
Launcher-Agent-Class
(and Premain-Class) manifest attribute so the JVM itself attaches
hloader as a java.lang.instrument agent before the target's own
main() runs, then embeds hloader's own runtime (agent, mod loader,
Mixin, and their dependencies) into the target jar so the result runs
completely standalone via java -jar.Rewrites
(URLClassLoader) someClass.getClassLoader() into a call to
ClasspathUrls.wrap() wherever it appears in any loaded class.Pre-1.6 Minecraft loads its game classes through a custom, child-first classloader
(
net.minecraft.launchwrapper.LaunchClassLoader) that only delegates to its parent (the
real system classloader) for package prefixes it's explicitly told to.CLI entry point: patch a jar, or patch-and-run it in one step like a launcher would.
One instance per mod jar, so two mods bundling different (and differently-versioned) copies of
the same library never collide - each mod's own dependency classes are only ever visible
through its own loader, not to any other mod.
Handed to a mod's lifecycle methods so it can log and identify itself.
Lifecycle hooks for an hloader mod.
Parsed
hloader.mod.json.Reads each mod jar's
hloader.mod.json, keyed to the jar it came from - the caller
needs the jar path to give each mod its own ModClassLoader.Reads back the obfinvalid input: '<'->named mapping data the Gradle plugin bundles into each mod jar as
hloader/mappings.srg, and bridges obf/named class, method and field names at runtime -
used both by HloaderBytecodeProvider (to find a named class's obfuscated bytecode) and
to produce human-readable copies of mixin-transformed classes for debugging.