Illegal reflective access by ExecutorServiceMetrics

[danishnawab]

Ran into the following warning at runtime when trying to monitor an ExecutorService using the micrometer binder ExecutorServiceMetrics:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics (file:.../micrometer-core-1.5.1.jar) to field java.util.concurrent.Executors$DelegatedScheduledExecutorService.e
WARNING: Please consider reporting this to the maintainers of io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

The following test reproduces the issue:

import io.micrometer.core.instrument.binder.jvm.ExecutorServiceMetrics;
import io.micrometer.core.instrument.simple.SimpleMeterRegistry;
import org.junit.Test;

import java.util.concurrent.Executors;

public class MicrometerTest {
    @Test
    public void illegalReflectiveAccess() {
        ExecutorServiceMetrics.monitor(new SimpleMeterRegistry(), Executors.newSingleThreadScheduledExecutor(), "monitoredExecutor");
    }
}

The issue is observed on both of the following runtimes:

openjdk version "14.0.1" 2020-04-14
OpenJDK Runtime Environment Zulu14.28+21-CA (build 14.0.1+8)
OpenJDK 64-Bit Server VM Zulu14.28+21-CA (build 14.0.1+8, mixed mode, sharing)

openjdk version "14" 2020-03-17
OpenJDK Runtime Environment AdoptOpenJDK (build 14+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14+36, mixed mode, sharing)

The aforementioned reflective access can be seen at line 290 of the ExecutorServiceMetrics.java

[izeye]

Some metrics from the binder depend on reflective access to Executors's internal implementation details, but Java 9+ warns illegal reflective accesses.

There are some options, for example:

1. Remove the reflection-based feature.
2. Opt in the feature.
3. Opt in the feature only for Java 9+.
4. Opt out the feature.

I created #2185 to resolve this with the option 4 as it's backward-compatible and also provides an option to avoid the warnings at the expense of losing the feature.

I'm not sure if there's any better fix for it.

[shakuzen]

I'd like to take a closer look at this and see if there's some way we could achieve our goal without the illegal reflective access, even if that might require changes in the JDK.