raphw / raphw/byte-buddy

Proper way to repackage ByteBuddy into the library

Open
#670 19 comments 1 reaction 1 assignee View on GitHub

@raphw is already working on this.

Since Jun 24, 2019.

enhancement question
Dominant language
Java
Stars
6.9k
Forks
855
PR merge metrics
No merged PRs in 30d

Description

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?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.