For years I have been annoyed by having our custom ByteBuddy build in Kanela, especially because the actual changes are minimal but required every time we want to bump the ByteBuddy version, which usually happens when we want to support new Java versions. Somehow Kanela was always a black box to me, a box that @dpsoft maintained for long time but lately he doesn't have time to maintain anymore, so I decided to that its time to take ownership of Kanela and try to solve these inconveniences once and for all.

I created a new project and tried my best to copy and distill down to the features and code that we actually use in Kamon. In the process I also:

1. Removed vavr and several other dependencies that I'm not sure we really needed
2. Ignored all the code that we don't use. Things like the EventBroker, Reinstrumenter, stoppable modules. They have been there for ages
3. Ignored the code that was specific to supporting Java versions older that Java 1.5 (yes, we had that. Kanela is that old!)
4. Tried to condense the code as much as possible. In some parts we had several levels of indirection or related logic spread across many classes that made it pretty hard to reason about how Kanela works
5. Tried to keep all the APIs the same so that all current instrumentation should work when we move to the new agent

As implementation details, if you look at the work @hughsimpson did at https://github.com/kamon-io/kanela/pull/160/files#diff-453ff6f7f27a9f4c86c4e8bac64f766ee1a93cdc3c7c7c43b69dcc17433e1a80 in an attempt to automate creating that patched ByteBuddy jar, there are a few changes:

1. Keeping the asm-tree and some parts of the asm-commons dependencies. The new kanela-dependencies project takes care of having the right dependencies in place and shading them in the same way that the ByteBuddy build would have
2. Removing default and interface from the list of reserved keywords. The Akka/Pekko/http4s instrumentations use the word interface as argument names and that makes ByteBuddy unhappy. I didn't get to test this yet, but I'm hoping that we will be able to workaround it without a custom build. I'd rather do a nasty reflection hack to modify that set that having a separate build just for that.

Things that need to be done:

• Figure out where to put this code. I started it in this repo just because I thought it would be easier to test all instrumentation and tweak things in the process, but probably this should be in the Kanela repo. The shading in kanela-dependencies can make IntelliJ unhappy (it works fine from metals, though)
• Figure out if we want to keep this compatible with Java 8. I used some records around but we could revert that so that this woks with Java 8, although in general I do want to move Kamon to be Java 17+
• Write a few more tests to cover bridges and mixins
• Test all the instrumentation with the new agent
• Implement bootstrap classloader injection, but only for the executors module
• Implement the listeners we use for the instrumentation status in the status page