Closed stevenschlansker closed 1 year ago
pretty ping?
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.
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.
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.
Hi @kaqqao , we ran into some behavior that we don't understand over at https://github.com/jdbi/jdbi/pull/2306
This code works as you'd expect when the enclosing class
Foo
has no type parameter - but when you introduce a parameterFoo<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!