Support for just resolving type variables

[jroper]

Added support for just resolving type variables into classes/parameterized types etc.

This is one possible solution for #8.

This is useful for when you have a method reference, and you want to find out what its arguments are, including generic type argument information.

To implement this, I look up the method specified by the method ref from the class that the method ref lives on.

One limitation is that it doesn't actually work for lambdas, it only works for method references (ie, using the :: syntax), since the Java compiler does not include generic type information in the generated synthetic methods for the lambda. I don't think there's anything that can be done about this, short of raising a bug on javac to ask that lambda methods get generated with full type information.

[jhalterman]

Awesome contribution!

This seems to work good for method refs, but for non-method refs, resolving ParameterizedTypes doesn't really buy us much since they still may contain TypeVariables that need to be resolved (ex: Optional<T>).

#8 was somewhat calling for an API that returns ParameterizedType instances (or something similar like our own GenericType class) where the actualTypeArguments are fully resolved - no variables. I'd love to do that as part of this work, since adding another resolution mechanism - even though it benefits method refs - would be confusing if it were only useful for method refs.

What do you think?

[jroper]

To be honest, my understanding of the Type hierarchy, including actualTypeArguments, and what may be returned in what contexts, is somewhat limited - the changes I made here were guided by what I saw being returned in a debugger, and there were lots of branches of code (specifically where subclasses of Type that my particular use case didn't use were being handled) that I didn't bother to handle at all, mainly because I had no idea what could be returned in what circumstances. So I'm not at all surprised that you think it could be improved, but at the same time my understanding of how it should be improved I don't think is enough to improve it.

So maybe it would be best to see this as PR as a guide for how to handle one use case, that someone else may want to build on in future?

[jhalterman]

Sure, no problem. I'll probably pick up this PR and add onto it a bit, using it as an excuse to add proper GenericType support to address #8. I really like the commit for how it improves method ref resolution, we just need to unify that work behind an API that is usable for other cases as well.

[jroper]

Sounds like a plan.

[lorenzleutgeb]

I would like to pick this up again, since I have a use-case for it.

However, please @jhalterman re-read the changeset and proposals, and reformulate what should be done/how these changes should be integrated before I start working. I am asking for this since this is a very old PR, and I would like to get your updated view on it in order to avoid wasting my energy.

[jhalterman]

@lorenzleutgeb I don't have any firm ideas on this, but the general high level idea would be to add a new resolve capability that resolves a container type like GenericType. For example:

class SomeFunction extends Function<String, List<Boolean>> {}

List<GenericType> args = resolveArguments(Function.class, SomeFunction.class);

GenericType stringArg = args.get(0);
GenericType listArg = args.get(1);

assert stringArg.getRawClass() == String.class;
assert listArg.getRawClass() == List.class;
GenericType booleanArg = listArg.getArgument();
assert booleanArg.getRawClass() == Boolean.class;

// And also
assert listArg.equals(new GenericType<List<Boolean>>() { });

[lorenzleutgeb]

@jhalterman you might want to consider closing this since #46 was merged, or is there something that I missed?