Access RecordComponent via Class.forName.

[eamonnmcmanus]

This should mean that GraalVM will understand the reflective lookup of its methods. See documentation.

Fixes #2464.

[Marcono1234]

Looks good and it appears your investigation is correct. If I change the code of ReflectionHelper to rethrow the NoSuchMethodException and then use the GraalVM Native Image Maven Plugin, the exception is indeed about a method of RecordComponent:

Caused by: java.lang.NoSuchMethodException: java.lang.reflect.RecordComponent.getName()
    java.base@17.0.8/java.lang.Class.checkMethod(DynamicHub.java:1038)
    java.base@17.0.8/java.lang.Class.getMethod(DynamicHub.java:1023)
    com.google.gson.internal.reflect.ReflectionHelper$RecordSupportedHelper.<init>(ReflectionHelper.java:223)
    com.google.gson.internal.reflect.ReflectionHelper$RecordSupportedHelper.<init>(ReflectionHelper.java:212)
    com.google.gson.internal.reflect.ReflectionHelper.<clinit>(ReflectionHelper.java:35)
    [...]

With your change it becomes a Graal exception which the user probably has to fix (and which should not or cannot be solved by Gson I assume):

Caused by: com.oracle.svm.core.jdk.UnsupportedFeatureError: Record components not available for record class com.google.gson.native_test.Java17RecordTest$MyRecord. All record component accessor methods of this record class must be included in the reflection configuration at image build time, then this method can be called.
    org.graalvm.nativeimage.builder/com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:92)
    java.base@17.0.8/java.lang.Class.getRecordComponents0(DynamicHub.java:1160)
    java.base@17.0.8/java.lang.Class.getRecordComponents(DynamicHub.java:2436)
    [...]

(though I am not familiar with Graal so I might have made a mistake in my test setup)

[Marcono1234]

Do you think it would be worth adding a GraalVM Native Image integration test to Gson? I have already an unfinished proof of concept locally which uses the Testing Support of the GraalVM Native Image Maven Plugin, and that seems to work.

However, because execution requires GraalVM and because building the native image for testing is quite resource intensive (more than 1GB of memory for me, and 100% CPU usage) it would probably only make sense to have that enabled for the GitHub workflow, and not be part of the normal Maven build which you execute locally.
Though because it is so resource intensive I am not sure if this is really worth it, what do you think?

[eamonnmcmanus]

If you already have such a test, I think it would be a great idea to add it to the CI. I felt bad about not adding a test for this PR, and I think your test could potentially cover that. If it turns out to be a really huge burden on the CI then we might change our minds, but otherwise I think it's good to be covered.

[eamonnmcmanus]

By the way, thanks for checking all those details!

[Marcono1234]

By the way, thanks for checking all those details!

No problem! It was also interesting for me to become a bit more familiar with this. Though I am still not that familiar with it, so I hope the integration test added in #2466 is reasonable and correct.