Search code examples
javasentryjpackage

Sentry intialization crashes with a NoSuchMethodError trying to find jdk.internal.reflect.Reflection.registerMethodsToFilter

I'm using jpackage (part of jdk14+) to build an MSI for windows installation of my java application. Everything packages and installs fine, but when I go to run the .exe it throws an exception while trying to initialize Sentry.

Exception in thread "main" java.lang.NoSuchMethodError: 'void jdk.internal.reflect.Reflection.registerMethodsToFilter(java.lang.Class, java.lang.String[])'
        at sun.misc.Unsafe.<clinit>(Unsafe.java:59)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Unknown Source)
        at com.google.gson.internal.reflect.UnsafeReflectionAccessor.getUnsafeInstance(UnsafeReflectionAccessor.java:70)
        at com.google.gson.internal.reflect.UnsafeReflectionAccessor.<init>(UnsafeReflectionAccessor.java:34)
        at com.google.gson.internal.reflect.ReflectionAccessor.<clinit>(ReflectionAccessor.java:36)
        at com.google.gson.internal.ConstructorConstructor.<init>(ConstructorConstructor.java:51)
        at com.google.gson.Gson.<init>(Gson.java:206)
        at com.google.gson.GsonBuilder.create(GsonBuilder.java:597)
        at io.sentry.EnvelopeReader.<init>(EnvelopeReader.java:28)
        at io.sentry.SentryOptions.<init>(SentryOptions.java:89)
        at io.sentry.SentryOptions.empty(SentryOptions.java:1559)
        at io.sentry.NoOpHub.<init>(NoOpHub.java:15)
        at io.sentry.NoOpHub.<clinit>(NoOpHub.java:13)
        at io.sentry.Sentry.<clinit>(Sentry.java:24)

This is using the latest sentry 5.2.0 library (tested all the way back to 4.2 and it still has the error though), and have tested JDK 14 through 17 to see if any of them work, which they don't.

Everything works fine if I'm running the .jar with java -jar program.jar, but it seems like jpackage creates an executable that doesn't work quite the same as simply running java.

Solution

  • The call to jpackage needed --add-modules jdk.internal.vm.compiler to fix this in JDK14, and by JDK17 it needs to be --add-modules jdk.unsupported instead.