Do not use shaded version of byte buddy when real one is present in the classpath #1060
Comments
|
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: mockk/mockk#15 |
|
Yes, I've seen that. But we cannot avoid shading, otherwise |
|
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 |
|
Let's wait for Rafael and act accordingly |
This way, it can work even with BlockHound on JDK8, which also uses ByteBuddy and thus was in conflict. Kind of solves #1060, but since now the debugging routine depends on BlockHound, where, it seems, the same problem was not fixed, the original cause for concern probably still stands.
This way, it can work even with BlockHound on JDK8, which also uses ByteBuddy and thus was in conflict. Kind of solves #1060, but since now the debugging routine depends on BlockHound, where, it seems, the same problem was not fixed, the original cause for concern probably still stands.
This way, it can work even with BlockHound on JDK8, which also uses ByteBuddy and thus was in conflict. Kind of solves #1060, but since now the debugging routine depends on BlockHound, where, it seems, the same problem was not fixed, the original cause for concern probably still stands.
This way, it can work even with BlockHound on JDK8, which also uses ByteBuddy and thus was in conflict. Kind of solves #1060, but since now the debugging routine depends on BlockHound, where, it seems, the same problem was not fixed, the original cause for concern probably still stands.
This way, it can work even with BlockHound on JDK8, which also uses ByteBuddy and thus was in conflict. Kind of solves #1060, but since now the debugging routine depends on BlockHound, where, it seems, the same problem was not fixed, the original cause for concern probably still stands.
This way, it can work even with BlockHound on JDK8, which also uses ByteBuddy and thus was in conflict. Kind of solves #1060, but since now the debugging routine depends on BlockHound, where, it seems, the same problem was not fixed, the original cause for concern probably still stands.
* Integration with BlockHound * Improve build configuration of integration tests * publication-validator is renamed to integration-testing; * Add an integration test for coroutine debugger java agent * Use JNA-based attach mechanism for dynamic attach Fixes #1821 Fixes #1060 Co-authored-by: Vsevolod Tolstopyatov <[email protected]> Co-authored-by: Sergei Egorov <[email protected]>
* Integration with BlockHound * Improve build configuration of integration tests * publication-validator is renamed to integration-testing; * Add an integration test for coroutine debugger java agent * Use JNA-based attach mechanism for dynamic attach Fixes #1821 Fixes #1060 Co-authored-by: Vsevolod Tolstopyatov <[email protected]> Co-authored-by: Sergei Egorov <[email protected]>
* Integration with BlockHound * Improve build configuration of integration tests * publication-validator is renamed to integration-testing; * Add an integration test for coroutine debugger java agent * Use JNA-based attach mechanism for dynamic attach Fixes Kotlin#1821 Fixes Kotlin#1060 Co-authored-by: Vsevolod Tolstopyatov <[email protected]> Co-authored-by: Sergei Egorov <[email protected]>
java.lang.IllegalStateException: Error during attachment using: kotlinx.coroutines.repackaged.net.bytebuddy.agent.ByteBuddyAgent$AttachmentProvider$Compound@38dee15caused byjava.lang.UnsatisfiedLinkError: Native Library /home/.../.sdkman/candidates/java/8.0.202-zulu/jre/lib/amd64/libattach.so already loaded in another classloaderThe text was updated successfully, but these errors were encountered: