long winded tweet incoming. summary: I have to break every coremod and tweaker completely. The api I designed 4 years ago is not really compatible with Java 8. The reason is stackmapframes. They were introduced but optional in J6 and provide extra type context information for the hotspot compiler, allowing it, I guess, to optimize the native bytecode or something (in reality i have no idea why they have done this, there's some interesting rants on the topic becuase it seems like this was added to make the verifier simpler, at the cost of pushing a lot of complexity into tech that does bytecode manipulation, like tweakers and coremods). In J7 they were still optional, but J8 has made them mandatory. If your class has ver. 52 or higher, it is required to have stackmapframes, and they need to be correct. If they're not, the verifier will error.
Note the key there: the class being loaded drives the rules for the optimizer, when loading that class.
Now, many modders are, whether or not Lex likes it, jumping to J8 - it has a lot of nice syntactic sugar. The problem is, those modders' dev envs are now recompiling Minecraft with v52 signatures, and coremods are NOT putting the right directives into their coremods to allow it to work. The reason this problem isn't widespread is because of this fact - only modders recompile Minecraft with J8, today (so the classes have v49 - J6, where this stuff is optional). But when Minecraft itself becomes J8 required, we'll all have this issue.
Can coremods add the right directives? No! They can't. If they do, we have a class circularity issue, because the directive forces classloading, when you're trying to byte code enhance, during classloading. 'Tis brilliant! This is why the api needs to change - coremods need to be handed ASM artifacts, and then I can circumvent class circularity issue in the tweaker system, rather than handing them bytearrays and letting them figure it out themselves.