It is not undefined behavior. Bytecodes are modified via custom CL and superclass was swapped from e.g. Object to something else. As for errors, honestly its been 23+ years so don’t really remember. Naturally you can’t just swap any random class - it has to be correct e.g. can’t have an override method in the child that has no corresponding method in the super. And if memory serves, you can also play this trick using classpaths. Assume a stub package com.foo.Context which is simply an extension of Object, and derive components from com.foo.Context.SuperClass. You simply need to provide a different eponymous package for the adapted instance of the code.
I've definitely experienced some scary bugs caused by runtime bytecode injection (from a tracing library). I didn't bother tracking it down further than identifying it was at the intersection of some slightly strange type and the tracing. Caused VM errors when this method was called but only when the tracing was configured.
Not saying it's not interesting to experiment with things like that, but there are non-trivial associated, if you ask me, to depending on it in production.
I'm pretty sure (but am hedging here :) that you would get any errors in the verification phase of loading a class. What you saw may have been due to bugs in that library you were using.
Anyway, this was before ASM and other bytecode engineering libraries. Today I would not directly hack the class def myself.
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...