common/org.js.lolifamily.minecraftmcp.patch/Instrumentations

Instrumentations

Self-attach + bootstrap-bridge injection, isolated from any class that references a bridge type.

Load-order critical: HotSpot verifies every method of a class when the class is linked, and linking Patch loads org.js.lolifamily.minecraftmcpbridge.Handler (super-interface of Patch.CountingHandler). So the bridge jar must already be on the bootstrap loader before Patch links — otherwise linking it fails with NoClassDefFoundError before its body, which would have done the injection, ever runs.

This object names no bridge type in a signature or supertype, so it links on its own — Patches.onEnter / Patches.onExit call it before touching Patch. arm's field write is not that: a PUTSTATIC owner resolves at first execution, which its guard keeps behind the injection.

Properties

bridge

private val bridge: Result<File>

The bridge jar to inject: the dev flag if set, else the copy embedded in our own mod jar.

bridgeJar

@JvmStatic

val bridgeJar: File?

For the compile classpath, where absence is survivable; ensure takes bridge itself, for the cause.

inst

@Volatile

private var inst: Instrumentation?

Functions

arm

fun arm(on: Boolean)

Mirror the authorization gate into PatchBridge.ARMED, where every woven advice reads it. What silencing a patch does and does not cover is on the field.

ensure

fun ensure(): Instrumentation

Idempotent: self-attach and inject the bridge jar to bootstrap, once.

extractEmbeddedBridge

private fun extractEmbeddedBridge(): File

Production fallback: extract the bridge jar embedded under mcp-bridge/ in our own mod jar. Fixed path, no cache key — two classes are cheaper to rewrite than to validate, and a key in the PATH (the old tmpdir/<jar>-<mtime>/) minted a new dir per mod install that nothing ever deleted.