# Creating a dependency on ExecutorInstrumentation

**URL:** <https://discuss.elastic.co/t/creating-a-dependency-on-executorinstrumentation/368149>\
**Category:** APM\
**Tags:** java\
**Created:** [October 2, 2024, 8:45pm UTC](https://discuss.elastic.co/t/creating-a-dependency-on-executorinstrumentation/368149 "2024-10-02T20:45:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![johngregg](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@johngregg](https://discuss.elastic.co/u/johngregg)\
**Post date:** [October 2, 2024, 8:45pm UTC](https://discuss.elastic.co/t/creating-a-dependency-on-executorinstrumentation/368149/1 "2024-10-02T20:45:06Z")

</div>

Friends,

I've written a couple of simple plugins to cover some unsupported cases in legacy code.

I'm considering another such case where all I really need is to extend co.elastic.apm.agent.concurrent.ExecutorRunnableInstrumentation and change the getTypeMatcher method.

Is this a reasonable dependency or should I consider ExecutorRunnableInstrumentation to be an implementation detail that I should not rely on?

thanks

---

<div class="post-metadata">

**Author:** ![Sylvain\_Juge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_juge/32/55521_2.png) [@Sylvain\_Juge](https://discuss.elastic.co/u/Sylvain_Juge)\
**Post date:** [October 3, 2024, 7:42am UTC](https://discuss.elastic.co/t/creating-a-dependency-on-executorinstrumentation/368149/2 "2024-10-03T07:42:29Z")

</div>

Hi,

Can you elaborate a bit on the unsupported cases in legacy code here ?

Generally speaking it's tricky to have cross-instrumentation dependencies, and maybe there are alternative ways than directly depending on instrumentation implementation details.

---

<div class="post-metadata">

**Author:** ![johngregg](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@johngregg](https://discuss.elastic.co/u/johngregg)\
**Post date:** [October 3, 2024, 6:53pm UTC](https://discuss.elastic.co/t/creating-a-dependency-on-executorinstrumentation/368149/3 "2024-10-03T18:53:42Z")

</div>

For the new case I have in mind, a team took the old util.concurrent library, renamed the packages, and added it to their own codebase. Supporting transferring the trace context across threads would be exactly like the agent does for java.util.concurrent except the package names are different.

---

<div class="post-metadata">

**Author:** ![Sylvain\_Juge](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sylvain_juge/32/55521_2.png) [@Sylvain\_Juge](https://discuss.elastic.co/u/Sylvain_Juge)\
**Post date:** [October 7, 2024, 7:04am UTC](https://discuss.elastic.co/t/creating-a-dependency-on-executorinstrumentation/368149/4 "2024-10-07T07:04:53Z")

</div>

In this case then it's probably better to just duplicate the existing instrumentation for `java.util.logging` and package it as an external [plugin](https://www.elastic.co/guide/en/apm/agent/java/current/plugin-api.html).

You could also maintain your own fork of the agent as well for this, as this won't be a common use-case.

As a side note, having to duplicate code from `java.util.concurrent` really seems like an anti-pattern for future maintenance:

- you will have to maintain this duplicated code over time and won't benefit from JVM enhancements in this area unless you keep up with it
- you will have to maintain your own instrumentation of fork for supporting it