Type parameters don't resolve when enclosing class has a type parameter

[stevenschlansker]

Hi @kaqqao , we ran into some behavior that we don't understand over at jdbi/jdbi#2306

    @Test
    void testGenericTypeWorksInParameterizedClasses() {
        abstract class TypeCapture<T> {
            private final Type type;

            protected TypeCapture() {
                this.type = GenericTypeReflector.getTypeParameter(getClass(), TypeCapture.class.getTypeParameters()[0]);
            }

            public final Type getType() {
                return type;
            }
        }

        class Foo<T> {
            void checkType() {
                assertThat(new TypeCapture<List<String>>() {}.getType()).isEqualTo(TypeFactory.parameterizedClass(List.class, String.class));
            }
        }

        new Foo<>().checkType();
    }

This code works as you'd expect when the enclosing class Foo has no type parameter - but when you introduce a parameter Foo<T>, suddenly the type parameter is lost in the TypeCapture class and this test fails.

Is this a bug in GeAnTyRef, or are we perhaps using it incorrectly? Thank you!

[hgschmie]

pretty ping?

[kaqqao]

Hey! I'll have a look at this today.
At first glance, I think this might be expected, because if the enclosing type is undecidable, so is the inner type (the inner type is the anonymous subclass in this case). But a partial resolution might be doable... I'll have to look deeper.

Btw, GeantyRef has TypeToken for capturing generic types, you may find it useful.

[kaqqao]

Ok, seems I was right. The issue is in the way TypeCapture is implemented. The short of it is that you don't actually have to call GenericTypeReflector.getTypeParameter in TypeCapture, because the generic type you're after is already fully captured in its direct super type, so it's enough to just do this:

protected TypeCapture() {
    ParameterizedType superType = (ParameterizedType) getClass().getGenericSuperclass();
    this.type = superType.getActualTypeArguments()[0];
}

With that, the test will pass.
EDIT: I now see you've already discovered this 😄

The long of it is that GenericTypeReflector.getTypeParameter tries to resolve the exact super type at the level where the variable is declared, e.g. if you have a type such as:

class StringList extends ArrayList<String> {}

and call GenericTypeReflector.getTypeParameter(StringList.class, List.class.getTypeParameters()[0]), it first has to resolve StringList as a List (because it is the List type that declares the variable), and that resolves to List<String>.

In your case, the anonymous inner class is a subtype of Foo<T>.TypeCapture<List<String>>, and because T is unresolvable, the whole super type isn't resolvable exactly.

I think I could implement partial super type resolution, e.g. getSuperType, as a complement to the existing getExactSuperType (similar to the getParameterTypes/getExactParameterTypes pair), and then add an overload of getTypeParameter based on that impl, if this is something you need? But as it stands, what you observed is the expected behavior.

[stevenschlansker]

Thank you for the explanation. We don't specifically need a method to handle this use case, it was just surprising to get such a non-specific result. If you think it would be useful to have in the API, we certainly would love to use it, but are happy enough with the code as it is.

We ship our own TypeToken type in Jdbi because we want to allow our users to pass in type tokens without exposing geantyref as part of our public API.