Bean methods with generic array/varargs parameters break native compilation

[eiswind]

When upgrading from 3.0.5 to 3.0.6 I find that having spring-boot-starter-hateoas on the classpath breaks the native build.

The error I see is

com.oracle.svm.core.util.VMError$HostedError: Registering type as reachable after analysis: AnalysisType<org.springframework.plugin.core.Plugin[]

I could make this go away by excluding the HyperMediaAutoConfiguration, which does not help if spring data is also on the classpath (there is a check for hateoas in spring data web configuration) which again breaks my build.

I created an mre at

https://github.com/eiswind/mre-hateoas-breaks-native

[wilkinsona]

Thanks for the MRE. This regression is due to changes in Spring Framework 6.0.8 and does not occur when setting spring-framework.version to 6.0.7. I believe the change that causes the problem is this one. @bclozel, should this be addressed in Framework or will Spring HATEOAS/Spring Plugin have to be updated to adapt to the Framework change?

[bclozel]

Let’s move this to Framework and figure out if this is a duplicate of oracle/graal#6510

[sdeleuze]

Looks like another GraalVM bug, same kind and inded related to the same change on Spring side, but a different one since using Spring Framework 6.0.9-SNAPSHOT or using latest GraalVM 23.1.0-dev build does not solve the issue.

It can be workaround by a org.springframework.plugin.core.Plugin[] reflection hint.

I am going to create a related GraalVM issue and bring it to the attention of GraalVM team.

[eiswind]

I can confirm that this workaround helps. I had already tried adding Plugin.class but using Plugin[].class does the trick.
Thanks for caring!

[sdeleuze]

Looks like indeed a GraalVM bug where a fix will be provided as discussed in oracle/graal#6529. It seems triggered by a bug in the GraalVM reflection metadata registration for generic arrays / varargs in OrderAwarePluginRegistry.of(T[]).

Like #30383, and as discussed during the latest Spring Framework weekly meeting, I am going to try to add a temporary workaround in order to handle this use case, and update #30394 to mention we should also remove this additional workaround when fixed on GraalVM side.