Any thoughts @aclement ?

I don't think these are all us directly but I think there are things we could do that would have a side effect of reducing them. sure I will take a look.

As suspected, not entirely under our control. For a few we can improve our hints but it isn't about tweaking a hint to mention specific members, the only way to fix these is absolutely not include a class in the reflect-config.json file at all, and we can't do that in all cases. Deeper dive:

For Spring not to fail, we have to mention some types in the reflect-config.json, we register them as simply as possible:

  {
    "name": "org.springframework.boot.autoconfigure.validation.ValidationAutoConfiguration"
  },

This enables Spring to be happy, we aren't configuring reflective access any deeper because we've already determined none of it is relevant (that configuration fails a ConditionalOnClass check, so we know the contents don't matter), so it doesn't matter that spring won't find methods on this type.

Unfortunately, even if you just lightly mention a class like that, GraalVM will validate all the fields/methods/etc. If there is any kind of reference that can't be resolved, the WARNING will come out. This includes references to types via generics. Now ValidationAutoConfiguration includes a method methodValidationPostProcessor that uses a type that may not be on the classpath javax.validation.Validator). So with our simple reference above in .json, we will get:

WARNING: Could not register reflection metadata for org.springframework.boot.autoconfigure.validation.ValidationAutoConfiguration. Reason: java.lang.NoClassDefFoundError: javax/validation/Validator.

We cannot get that to stop happening right now (well, we could craft more substitutions...but I'm not sure how many it would be). Even if we fully list the methods we do care about in the .json and skip methodValidationPostProcessor in that list, it doesn't affect what GraalVM will check, you'll still get the warning and there is no control on that warning, it is a sysout println (in ReflectionDataBuilder.java in GraalVM).

A solution to many of these warnings is coming. When we move to functional registration we won't need to mention these configurations at all (that contain unresolvable types), and the warnings will disappear. I'd say let's tackle the remaining ones when we get to 0.9.2 and functional registration, rather than spend a lot of time now patching Spring when it isn't the long term direction.

There are very few of these warnings now with 0.11 but until 0.11 is further along with the AOT infra all done and all samples passing I won't claim success. Right now for commandlinerunner there are 6 of these remaining related to AOP, and 10 for webmvc-tomcat.

I rewrote AOPHints and now commandlinerunner and webmvc-tomcat run with no warnings, but it is pretty certain other samples will trigger warnings once we are able to run them.

Thanks, let's continue to refine that with other samples, I think we can close this issue since it was about crazy amount of warnings. It seems as expected the behavior is much cleaner now.