Questions related to the contents of java.util.concurrent.** should generally be asked on the "Concurrency-interest" mailing list: http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
-Pavel > On 6 Jan 2021, at 03:11, Tommy Ludwig <tlud...@vmware.com> wrote: > > Hello, > > In the Micrometer project, we provide metrics instrumentation of > `ExectorService`s. For `ThreadPoolExecutor`s, we track the number of > completed tasks, active tasks, thread pool sizes, task queue size and > remaining capacity via methods from `ThreadPoolExecutor`. We are currently > using a brittle reflection hack[1] to do this for the wrapped > `ThreadPoolExecutor` returned from `Executors` methods > `newSingleThreadExecutor` and `newSingleThreadScheduledExecutor`. With the > introduction of JEP-396 in JDK 16, our reflection hack throws an > InaccessibleObjectException by default. > > I am not seeing a proper way to get at the methods we use for the metrics > (e.g. `ThreadPoolExecutor::getCompletedTaskCount`) in this case. Is there a > way that I am missing? > > From the JavaDocs, the intention of the wrapping is to prevent changing the > ThreadPool configuration. Our use case does not call for changing the thread > pool configuration - we want to observe the ExecutorService (e.g. thread pool > state) via getter methods for monitoring purposes. > > Thanks, > Tommy > > [1] > https://github.com/micrometer-metrics/micrometer/blob/25f120833f8b73e4bd7cf604831dfddf0112fe9c/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/jvm/ExecutorServiceMetrics.java#L272-L301 >
