Closed qwwdfsad closed 4 years ago
Note that reflective lookup is not the best option, probably we should first investigate whether it is possible to achieve with a regular Bute Buddy API
This also opens a can of worms with version compatibility.... I wonder if it is possible to "shade" native libraries, too?
I am not sure it could work. Take a closer look at the library: it is platform and JVM specific and is bundled with JDK. What should we shade in that case?
Uh. I see. That is really bad. It is not just "already loaded" it is already loaded in a different class-loader, and we we cannot get get hold on this class-loader, then we are out of luck completely....
Similar bytebuddy sharing conflict between mockk/mockito was solved by avoiding shading bytebuddy altogether: https://github.com/mockk/mockk/issues/15
Yes, I've seen that. But we cannot avoid shading, otherwise java -jar myApp.jar -javaagent:...
won't work.
Hello, I just ran into this issue trying to use kotlinx-coroutines-debug and mockk. I've resolved it for now by compiling the debug jar without the shaded ByteBuddy and including it in my project.
I imagine using kotlinx-coroutines-debug and a mocking library is a pretty common use case. Perhaps a different kotlinx-coroutines-debug artifact could be published with the unshaded ByteBuddy? Or the normal one could be unshaded, with a fatjar artifact with the shaded ByteBuddy for the -javaagent
uses?
https://github.com/raphw/byte-buddy/issues/670
Let's wait for Rafael and act accordingly
java.lang.IllegalStateException: Error during attachment using: kotlinx.coroutines.repackaged.net.bytebuddy.agent.ByteBuddyAgent$AttachmentProvider$Compound@38dee15
caused byjava.lang.UnsatisfiedLinkError: Native Library /home/.../.sdkman/candidates/java/8.0.202-zulu/jre/lib/amd64/libattach.so already loaded in another classloader