NullPointerException if passing an anonymous class to ReflectionsHint#registerType

[Artur-]

If you (accidentally in this case) pass an anonymous class to registerType it fails with

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because the return value of "org.springframework.aot.hint.AbstractTypeReference.getCanonicalName()" is null
	at org.springframework.aot.hint.AbstractTypeReference.equals(AbstractTypeReference.java:93)
	at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1214)
	at org.springframework.aot.hint.ReflectionHints.registerType(ReflectionHints.java:85)
	at org.springframework.aot.hint.ReflectionHints.registerType(ReflectionHints.java:98)
	at org.springframework.aot.hint.ReflectionHints.registerType(ReflectionHints.java:120)

This happened to us when trying to use

for (var c : reflections.getSubTypesOf(Converter.class)) {
     reflection.registerType(c, memberCategories);
}

and so it happens that Converter contains

public interface Converter<PRESENTATION, MODEL> extends Serializable {
...
    static <P, M> Converter<P, M> from(
            SerializableFunction<P, Result<M>> toModel,
            SerializableFunction<M, P> toPresentation) {
        return new Converter<P, M>() {
...

Seems like the org.reflections library returns Converter$2 as one of the sub types, which then fails when passed to registerType.

[Artur-]

Well for some reason it seems like adding com.vaadin.flow.data.converter.Converter$1 works fine but when it gets to com.vaadin.flow.data.converter.Converter$2 then it fails

[sdeleuze]

For this one, I think I would assert that the class passed to ReflectionTypeReference#of is not null and has a non null canonical name, in order to have a more meaningful exception earlier. That would also be consistent with the kind of checks done in SimpleTypeReference. cc @bclozel

@Artur- That will not change the fact you need to avoid passing such class to ReflectionHints in your code, I don't think silently ignoring such class-based type reference would be a reasonable behavior.

[sdeleuze]

@Artur- I implemented a solution that should fix the NullPointerException you see, keep a lenient behavior at ReflectionHints#registerType level, and assert that the class and related canonical name are not null at ReflectionTypeReference#of level.

We have a planned release tomorrow, so when the build is finished, would be great if you could test Spring Framework 6.0.6-SNAPSHOT to confirm it works as expected for you.

[Artur-]

I tried 6.0.6-SNAPSHOT but run into something that is already in 6.0.5

Exception in thread "main" java.lang.IllegalArgumentException: Code generation is not supported for bean definitions declaring an instance supplier callback : Root bean: class [null]; scope=singleton; abstract=false; lazyInit=null; autowireMode=0; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=null; factoryMethodName=null; initMethodNames=null; destroyMethodNames=null

Need to figure that one out first..

[Artur-]

Ok, Spring Boot vs Spring Framework conflict. With Spring Boot 3.0.3 + Spring Framework 6.0.6-SNAPSHOT everything works as expected, thanks!