Ideas about javaagent-tooling/api changes

[mateuszrzeszutek]

Recently we've been developing the extension loading mechanism, and thinking about keeping some javaagent instrumentations outside of this repo. Our current javaagent-api/tooling code is a bit messy and contains lots of stuff that we probably shouldn't expose to javaagent instrumentation authors. I had some thoughts about splitting the javaagent modules in a bit different way:

• javaagent-bootstrap: same as before, there's no need to change that;
• javaagent-advice-api: previous javaagent-api module. This module should contain classes that are supposed to be used in advice code: InstrumentationContext, CallDepth etc. Ideally instrumentation specific bootstrap classes (the undertow package for example) should leave in the instrumentation bootstrap modules (:instrumentation:undertow:bootstrap). We have a couple of internal classes here, some of them could probably live in javaagent-bootstrap;
• javaagent-api: previous javaagent-spi combined with those parts of javaagent-tooling that are supposed to be used by instrumentations that are not kept in this repo (contrib, 3rd party, vendor code): InstrumentationModule, runtime parts of muzzle, byte buddy matchers etc. No bytecode generation voodoo, this module should be easy on the eyes 😄
• javaagent-internal (tooling?): everything else from javaagent-tooling that's supposed to be used internally by the agent (and not by javaagent instrumentation authors).

WDYT?

[iNikem]

+1 for separating internal javaagent code from the one needed by external instrumentations authors

[trask]

There was previously interest in combining the javaagent-advice-api and javaagent-api artifacts (as defined above) into a single artifact (#1186 (comment)), and split them up in the build process to live in their different class loaders, with the idea it would be more user friendly than having two artifacts.

Though since these two artifacts live in different class loaders and can't really mix (call each other), it could also be less confusing to users to have them in separate artifacts (and cleaner for us).

Other thoughts

• Maybe javaagent-bootstrap -> javaagent-internal-bootstrap to signify that it's not really for public consumption
• I like javaagent-internal as defined above
• Maybe javaagent-api -> javaagent-extension-api to be clearer that it contains apis for all extension types (instrumentation and other distro extensions), though javaagent-api is shorter, so also good

[mateuszrzeszutek]

Though since these two artifacts live in different class loaders and can't really mix (call each other), it could also be less confusing to users to have them in separate artifacts (and cleaner for us).

This is exactly what I thought - if you have to depend on two different artifacts it makes it a bit more clear that you can't freely mix them. And it really is easier and simpler for us 😄

javaagent-api -> javaagent-extension-api

💯 👍
This matches the OTEL_JAVAAGENT_EXTENSIONS name nicely.