avast/datadog4s

Runtime error + app hangs when upgrading to Java 17

Closed this issue · 5 comments

marko-asplund commented

Describe the bug
Trying to migrate our app using from Java 11 to Java 17 I get the below runtime error and the app hangs. This prevents us from upgrading to Java 17.

Here's the runtime error we're seeing:

Exception in thread "io-compute-blocker-8" java.lang.IllegalAccessError: class com.avast.datadog4s.extension.jvm.JvmReporter (in unnamed module @0x663c9e7a) cannot access class sun.management.ManagementFactoryHelper (in module java.management) because module java.management does not export sun.management to unnamed module @0x663c9e7a
	at com.avast.datadog4s.extension.jvm.JvmReporter.<init>(JvmReporter.scala:67)
	at com.avast.datadog4s.extension.jvm.JvmMonitoring$.configured(JvmMonitoring.scala:26)
	at com.avast.datadog4s.extension.jvm.JvmMonitoring$.default(JvmMonitoring.scala:19)
	at com.wolt.courierpayments.modules.Monitoring$.$anonfun$createMetricFactory$1(Monitoring.scala:26)
	at cats.effect.kernel.Resource.loop$1(Resource.scala:189)
	at cats.effect.kernel.Resource.continue$1(Resource.scala:166)
	at cats.effect.kernel.Resource.$anonfun$fold$1(Resource.scala:177)
	at cats.effect.IO$.$anonfun$bracketFull$3(IO.scala:1442)
	at cats.effect.IOFiber.runLoop(IOFiber.scala:403)
	at cats.effect.IOFiber.execR(IOFiber.scala:1319)
	at cats.effect.IOFiber.run(IOFiber.scala:118)
	at cats.effect.unsafe.WorkerThread.run(WorkerThread.scala:555)

To Reproduce
Invoke JvmMonitoring.default[F](metricFactory) on Java 17.

Expected behavior
App should not hang and no exception should get thrown.

Additional context

tomasherman commented
marko-asplund commented

It seems to be working as a workaround - thanks! 👍
But I guess the code would also need to be updated to work with Java versions > 16 out of the box, right? 🤔

tomasherman commented

Yes, starting in java 16 oracle enforced their module verification system. To be honest, im not really sure how to approach this. The issue stems from the fact that by definition, when we try to monitor jvm itself, we need to latch on to the jvm internals classes that are 'protected' by the module system. I was not able to find any alternative, way back when.

Anyway I'm glad the workaround helped.

tomasherman commented

i will close this for now, feel free to reopen if you need to

tovbinm commented

Fix: add --add-opens=java.management/sun.management=ALL-UNNAMED as JVM parameter when starting the application