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
Comment From: 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?
Comment From: bclozel
Let’s move this to Framework and figure out if this is a duplicate of https://github.com/oracle/graal/issues/6510
Comment From: 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.
Comment From: 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!
Comment From: 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 https://github.com/spring-projects/spring-framework/issues/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 https://github.com/spring-projects/spring-framework/issues/30394 to mention we should also remove this additional workaround when fixed on GraalVM side.