3 ms·

> I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of e

> I used to do the switch the superclass at loadtime to experiment with adaptable programs. This probably falls in undefined behavior territory. What kind of errors did you get when something went wrong?

eternalban 6y ago
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. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
- hderms 6y ago
  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.
  - eternalban 6y ago
    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.

eternalban 6y ago

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. https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...

hderms 6y ago
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.
- eternalban 6y ago
  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.