Proper way to repackage ByteBuddy into the library

Some context:

We at kotlinx.coroutines have a special “debug” library that uses ByteByddy to redefine some classes for the sake of better user experience.

Our API shape has two modes:

1. Programmatic API using self-attach mechanism. Everything works fine, a user has our jar (and thus ByteBuddy) in the classpath.
2. Attach mechanism. If a user already has its own application without our library in the classpath, we don’t want to force them to recompile their project. So to make it as simple as java -jar myapp.jar -javaagent:kotlinx-coroutines-debug.jar we’ll have to shade ByteBuddy into our library. But then we can mess up with other libraries that use ByteBuddy, especially in case of incompatible versions. To avoid that, we not only shade but also repackage ByteBuddy.

It works fine most of the time but fails with java.lang.UnsatisfiedLinkError: Native Library /.../jre/lib/amd64/libattach.so already loaded in another classloader when the target application uses libraries that also use ByteBuddy (e.g. Spring or Mockito).

So the question is, what is the best way to have a self-contained JAR suitable for attach and that also works with other libraries that use ByteBuddy?

[elizarov]

Thanks. JNA use is indeed safer. If we include it as a “plain” dependency, then there’s still a risk of a version conflict on JNA. However, if you use “separate classloader” trick, then it indeed works – JNA can be safely loaded from multiple classloaders 🎉 (I have not explicitly checked if it holds for the case of pre-main, but I don’t see how it should be different). Interestly, though, behind the scenes two JNA instances share one copy of the loaded native library, but create different proxies to it.

[raphw]

FYI: I extended Byte Buddy agent such that it is now possible to attach to a VM without using the JDK-specific tools.jar. I simply reimplemented the attach API for OpenJ9/HotSpot on Solaris/Windows/POSIX which is now a part of Byte Buddy.

All you need to do is to include JNA for this. Note however that JNA is not shadable due to its use of JNI.

However, this mechanism is not vulnerable to being loaded by multiple class loaders. Maybe instead of shading you can isolate Byte Buddy agent and JNA in a seperate class loader and work around that way? Due to the possibility of using Byte Buddy agent in a premain state, it is not trivial to work around the shading, unfortunately but I will investigate further.

As a bonus, with the JNA-based solution, you can self-attach on non-JDK VMs if this is relevant to you.