Avoid Illegal Reflective Access Warning on JDK11

[ivantopo]

This happens when running on JDK11:

[ERROR] WARNING: An illegal reflective access operation has occurred
[ERROR] WARNING: Illegal reflective access by kamon.instrumentation.executor.ExecutorInstrumentation$ (file:/Users/roman/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/io/kamon/kamon-bundle_2.12/2.0.0-RC2/kamon-bundle_2.12-2.0.0-RC2.jar) to field java.util.concurrent.Executors$DelegatedExecutorService.e
[ERROR] WARNING: Please consider reporting this to the maintainers of kamon.instrumentation.executor.ExecutorInstrumentation$
[ERROR] WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
[ERROR] WARNING: All illegal access operations will be denied in a future release

I'm not sure of how we could get around this, but let's see if there is a way! Thanks to @bogdanromanx for bringing this up!

[DieBauer]

Got the same issue: #610

[DieBauer]

I think this line: https://github.com/kamon-io/kamon-executors/blob/master/kamon-executors/src/main/scala/kamon/instrumentation/executor/ExecutorInstrumentation.scala#L243 is where the warning occurs.

[alexmnyc]

Getting the same warnings

[red-benabas]

Also getting warnings on Java11

[Liorba]

hey all!
any updates on that?

[pawelkrupinski-ovo]

Ping

[sebarys]

I'm also receiving this when using Java 11

[dpsoft]

Hi all, a workaround until we find a good solution is adding --add-opens java.base/java.util.concurrent=ALL-UNNAMED as JVM param.

[ivantopo]

yo @dpsoft, is there any particular reason why we are supporting those DelegatedExecutorService implementations? I have seen the code the since long time ago and just kept it there. But as I'm searching through the libraries we instrument, there are no usages of Executors.unconfigurable..., which is the only way to get an instance of those executors.

If there is no real need to unwrap the delegated implementations, it might be a good idea to just remove them from the instrumentation. WDYT?

[oschrenk]

Hi all, a workaround until we find a good solution is adding --add-opens java.base/java.util.concurrent=ALL-UNNAMED as JVM param.

Thanks.

Using

    javaOptions in run ++=  Seq("--add-opens","java.base/java.util.concurrent=ALL-UNNAMED"),

for now, suppresses the warnings

[vinodkumarsalimeti]

@oschrenk, I have tried to suppress the warnings using
javaOptions in run ++= Seq("--add-opens","java.base/java.util.concurrent=ALL-UNNAMED"),
But it's not working for me, did it worked for you?

[vinodkumarsalimeti]

I am not able to see any warnings when i run application using sbt run in terminal, but when i create a docker image and run the application inside docker container i am able to see the warnings.

[oschrenk]

The option I used is indeed only used for sbt. If you package your application you need to provide the JVM options for your packaging solution.

If you happen to use sbt-native-packager to create your docker image, this should work

    javaOptions in Universal ++= Seq(
      // -J params will be added as jvm parameters
      "-J--add-opens",
      "-Jjava.base/java.util.concurrent=ALL-UNNAMED"
    ),

But again, that depends on the way you package your application.

[vinodkumarsalimeti]

Thanks @oschrenk , it has solved my problem with your suggested code

javaOptions in Universal ++= Seq(
  // -J params will be added as jvm parameters
  "-J--add-opens",
  "-Jjava.base/java.util.concurrent=ALL-UNNAMED"
),

[dpsoft]

yo @dpsoft, is there any particular reason why we are supporting those DelegatedExecutorService implementations? I have seen the code the since long time ago and just kept it there. But as I'm searching through the libraries we instrument, there are no usages of Executors.unconfigurable..., which is the only way to get an instance of those executors.

If there is no real need to unwrap the delegated implementations, it might be a good idea to just remove them from the instrumentation. WDYT?

@ivantopo you are right, there is no reason to maintain this code! I will make a PR removing this unused code.

UPDATE

The reason that we need that code is because every ScheduledThreadPoolExecutor created by Executors is wrapped and we need unwrap the underlying ThreadPoolExecutor in order to extract the metrics: https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/concurrent/Executors.java#L681-L687

Maybe an option could be using kanela to redefine modules to export/open the required packages or instrument Executor adding an accessor method in order to avoid the reflection call (agent required).

ideas are welcome!