Rafael Winterhalter
Rafael Winterhalter
For using `@Morph`, you need to install a binder: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/implementation/bind/annotation/Morph.java#L153
This might relate to a clean up I did with regards to method visibility. There is a check for visibility and accessibility. The errors here can be rather subtle. Typically,...
Method delegation is designed to avoid this. Try out `Advice` where you inline code into the instrumented method and operate on the actual arguments.
Yes, you would need to use Advice for this.
This means that Byte Buddy is likely used in a way that uses Unsafe. Typically for loading classes. This can likely be substituted by using method handles, but this is...
It's used by `net.bytebuddy.dynamic.loading.ClassInjector$UsingUnsafe`, but it can of course be resolved by using a different `ClassInjector`.
You can set `-Dnet.bytebuddy.safe=true` already to avoid Byte Buddy making an attempt. Once the possibility goes away, Byte Buddy will simply fail upon attempting to use reflection, then you will...
Not quite my field of expertise, but maybe @LikeTheSalad could comment here?
You can already set `-Dcom.ibm.tools.attach.directory=/tmp/.com_ibm_tools_attach` which is the official mechanism in OpenJ9. Would this be an option to define in this container?
I am not that familiar with the Android space these days, but the exception message seems self-explanatory: On Android P, a class injection can only be applied to BaseDexClassLoader. I...