Redesign `ResolvedType` to be a generic interface that does not implement `Type`

[garretwilson]

@cowtowncoder I'm in the middle of creating an abstract database interface that involves transparent storage of objects (initially Java record) with full type conversions. For a corner of the conversion I'm using Jackson ObjectMapper, although I'm not sure about what I will use long-term. In any case I had a chance to dig into my old PLOOP code (described in #37) and how it relates to ResolvedType (see e.g. our discussion in #69). There are several tensions lurking in those discussions, as well as the proposal I made in #76 that GenericType<T> should not really be a java.lang.reflect.Type.

For this current work I just now had a long and in-depth conversation with one of the top LLMs, refreshing my memory about these issues and understanding what it would look like to bring PLOOP up to date and carry it forward using ClassMate. The benefit here is that in our discussion we started with actual, practical, working code that we had just implemented in this database framework. We looked at how our new implementation could be generalized by bringing in PLOOP+ClassMate. We came upon some important insights, which I believe form a synthesis of the tensions I was feeling in those other tickets, especially in light of the new PR #103 which basically tries to reverse a ResolvedType back into a Type. Below is a summary (produced by the LLM) of those insights. I leave a few additional comments at the end.

---

ClassMate ResolvedType Design Insights

Background

This builds on discussions from #37 (PLOOP properties layer, 2017), #69 (ResolvedType → JavaType conversion), and the draft PR #103 (ResolvedTypeMapper). These issues circle around the same fundamental design tension in ClassMate's type abstraction.

The Core Problem

ResolvedType currently implements java.lang.reflect.Type, which appears to offer seamless interoperability. However, Type has subtype interfaces (ParameterizedType, GenericArrayType, TypeVariable, WildcardType) that code routinely inspects:

Type type = ...;
if (type instanceof ParameterizedType pt) {
    Type[] args = pt.getActualTypeArguments();
    // process generic arguments
}

ResolvedType doesn't implement these subtypes. Code that receives a ResolvedType through a Type reference and checks instanceof ParameterizedType gets false—silently losing all generic information. This affects Jackson's TypeFactory, Hibernate Validator, and any API that inspects Type structure.

PR #103 addresses this by creating a ResolvedTypeMapper that synthesizes proper ParameterizedType and GenericArrayType implementations from ResolvedType data. This works, but it's an external workaround for what should be built-in behavior.

ResolvedType as a Type Replacement

The insight from working with these APIs is that ResolvedType should be understood as a replacement for Type in application code, not an implementation of it.

Within an application, you'd use ResolvedType everywhere—passing it through property descriptors, converters, serializers. You'd only touch Type at boundaries:

• Input: Converting from Field.getGenericType(), RecordComponent.getGenericType(), etc.
• Output: Converting to Type when calling external APIs (Jackson, Hibernate, etc.)

This positions ResolvedType as a richer abstraction that shields application code from Type's design limitations while remaining interoperable.

Why ResolvedType Should Be Generic

Java's reflection types aren't generic—ParameterizedType.getRawType() returns Type, not Type<T>. This forces runtime casts and loses compile-time safety:

Type listType = field.getGenericType();  // List<String>
Class<?> raw = getRawType(listType);
Object result = raw.cast(someValue);  // no compile-time safety

A generic ResolvedType<T> would preserve type safety through the chain:

ResolvedType<List<String>> listType = resolver.resolve(field);
Class<List<String>> raw = listType.erasedClass();
List<String> result = raw.cast(someValue);  // type-safe

This matters for frameworks passing type information through multiple layers.

Why ResolvedType Should Be an Interface

ClassMate's value is resolving type variables through inheritance hierarchies. But not all contexts need that resolution:

record User(String id, List<String> tags) {}

For records, RecordComponent.getGenericType() returns fully-specified types. ClassMate resolution adds overhead without benefit.

If ResolvedType were an interface, there could be multiple implementations:

• Simple wrapper: Stores the original Type directly; toType() returns it unchanged
• Resolution result: ClassMate-backed; toType() synthesizes a Type from resolved data

Both satisfy the same interface. Consumers don't know or care which implementation they receive.

The toType() Bridge

Rather than implementing Type (which fails instanceof checks), ResolvedType should provide an explicit toType() method that returns a proper Type hierarchy:

• For simple wrappers: return the stored original Type
• For resolution results: synthesize ParameterizedTypeImpl, GenericArrayTypeImpl, etc. (as PR Draft: Issue #69 | Add ResolvedTypeMapper to convert ResolvedType into Type #103 does)

The synthesized types implement the correct interfaces, so instanceof ParameterizedType works as expected. External APIs receive types they can inspect normally.

This is essentially what PR #103 provides externally. Building it into ResolvedType would make it a first-class capability.

Proposed Design Sketch

public interface ResolvedType<T> {
    Class<T> erasedClass();
    List<ResolvedType<?>> typeArguments();
    Optional<ResolvedType<?>> typeArgument(int index);
    
    boolean isParameterized();
    boolean isArray();
    Optional<ResolvedType<?>> arrayComponentType();
    
    Type toType();  // original or synthesized
    
    // Factory methods
    static <T> ResolvedType<T> of(Class<T> clazz) { ... }
    static ResolvedType<?> of(Type type) { ... }  // simple wrapper, stores original
    static ResolvedType<?> resolve(Type type, Class<?> context) { ... }  // full resolution
}

Key design points:

• Interface, not abstract class—allows implementation flexibility
• Generic <T> parameter—preserves compile-time type safety
• Does not implement java.lang.reflect.Type—avoids instanceof failures
• toType() method—explicit bridge for external API interoperability
• Multiple factory methods—simple wrapping vs. full resolution

Summary

ResolvedType currently occupies an awkward middle ground: implementing Type suggests compatibility, but the subtype contracts aren't satisfied. PR #103 demonstrates that users need proper Type representations for external APIs, but the current design forces external workarounds.

The proposed redesign clarifies ResolvedType's role: a richer, type-safe replacement for Type within application code, with an explicit toType() bridge for interoperability. Making it an interface enables both lightweight wrappers (preserving original types) and full resolution results (synthesizing types), unified under a common abstraction.

---

This raises lots of questions which we can discuss in the comments. e.g. Is ResolvedType the best name for this new, redesigned thing? Are you interested in going in this direction for a new major ClassMate version?

For the short term in my framework I will create this general, improved ResolvedType interface (probably with a different name), with factories that produce it. The early iterations may have ClassMate and the current ResolvedType serving as backing implementations, depending on how much this helps go forward quickly. Longer term I would hope that this interface on our end could be replaced with a redesigned ClassMate ResolvedType, whatever its name; and/or integrated with PLOOP.

I would also be interested in discussing the possibility of working with you for a new ClassMate that might even have a separate property description facility mentioned in #37 and possibly even used eventually in a new version of Jackson. (With LLMs such large-scale thinking and refactoring suddenly becomes much more feasible, even producing better results than if humans were to painstakingly pore over the code—as long as innovative, design-oriented humans direct and guide the LLMs.)

[cowtowncoder]

Quick notes...

First of all, most of changes would require major version bump, or fork (which "proper" Java library major version bump often needs to be anyway, see Jackson).

With that, there are sort of 2 tracks:

1. What, if anything (... some toJDKType() conversions?) to target for 1.x
2. If and how to pursue bigger version bump: both
   a. Practical (new coordinates? new repo? (i.e. fork)) and
   b. Functionality/design

On 2 b, my initial gut reaction is

• ResolvedType as a Type Replacement (not instance). Yes, indeed.
• ResolvedType an interface... maybe, not feeling strongly here. Example wrt Record tho makes zero sense to me; Records require resolution same as POJOs (for List<String> fields etc)
• ResolvedType generic: no, I don't think so. LLM may be misguided here; trying to use generic for use like this is more likely an anti-pattern in actual use -- code ends up fighting against generic typing. Esp. if trying to parameterize along java.lang.reflect.Type

On 1, we should probably consider fate of #69 / #103.

Idea of something like toJDKType() for ResolvedType sounds like reasonable path wrt 1.x, but maybe I forget something.

[cowtowncoder]

Oh and on whether to go with Big Redesign... I don't know. Right now my bandwidth is somewhat limited, to be honest.

[garretwilson]

Thanks for reading, @cowtowncoder . My objective was just to gather all my thoughts on this topic over the years, together with some deeper insights that I gained while using an LLM to help me remember the context of all this. Even if you do not decide to go in a large-scale refactoring, I thought you might be interested in this synthesis and proposal.

To clarify, this insight was based upon a revisiting of ClassMate in relation to an actual implementation I'm working on, together with a discussion using an LLM as a soundboard. Although te LLM produced the summary of my thoughts, this is not a proposal the LLM dreamed up on its own.

ResolvedType an interface... maybe, not feeling strongly here. Example wrt Record tho makes zero sense to me; Records require resolution same as POJOs (for List<String> fields etc)

In trying to remember why ClassMate is useful in the context of the application I'm working on, I confess that I did rely on the LLM's assertion that ClassMate resolution is not needed for record. When I presented it with your reaction, it qualified what it had stated:

ClassMate is needed for record component types if and only if the record itself is generic.

That's it. That's the complete rule.

Record Declaration	Component Type	getGenericType() Returns	ClassMate Needed?
record User(List<String> tags)	List<String>	ParameterizedType for List<String>	No
record Box<T>(T value)	T	TypeVariable for T	Yes
record Wrapper<T>(List<T> items)	List<T>	ParameterizedType with TypeVariable inside	Yes

What the ClassMate Author Likely Meant

When he said "Records require resolution same as POJOs (for List<String> fields etc)", I believe he was thinking of case 3 above:

record Wrapper<T>(List<T> items) {}

If you have a Wrapper<String>, the component's declared type is List<T>. You need ClassMate to resolve that to List<String>. His parenthetical "(for List<String> fields etc)" referred to arriving at List<String> through resolution, not starting with it.

Is that what you meant? And is the LLM's assertion that "ClassMate is needed for record component types if and only if the record itself is generic" correct? If not, let me know. I haven't dug deep into your ClassMate resolution code, so if there are other instances other than a generic record in which resolution is needed, I want to know!

Nevertheless if we agree that most records (I don't know; I'm just guessing) aren't generic (and there are doubtless other cases in which the ResolvedType "factory" could tell that resolution were not needed), I still see value of the case in which a lightweight ResolvedType interface implementation would simply wrap around the original Type would be probably more efficient than carrying around all that ResolvedType carries around now, and without the need to reconstruct the Type in the new toType() method.

ResolvedType generic: no, I don't think so. LLM may be misguided here; trying to use generic for use like this is more likely an anti-pattern in actual use -- code ends up fighting against generic typing. Esp. if trying to parameterize along java.lang.reflect.Type

We can't blame this one on the LLM. 😄 This was something I had already added to PLOOP, and I mentioned that two years ago on #69:

If only there were a ResolvedType.getType() or something that would give me back the original type—or some (reasonably short) algorithm to reconstruct it.

If there is not, after I pull out my PLOOP library and dust it off, I may improve its TypeInfo<T> class to store, not only the ClassMate ResolvedType, but also the original Type that was used as input to TypeResolver. This will give me a convenient TypeInfo<T> type holder to pass around, providing me acess to ResolvedType but also giving me the original Type in case I need to use it with Jackson.

This generic PLOOP TypeInfo<T> I referred to is something I wrote back in 2017:

/**
 * A value class for representing a ClassMate {@link ResolvedType} along with its original generics-erased type.
 * <p>
 * This class is a lightweight wrapper for {@link ResolvedType} that regains the captured generics that are not available from
 * {@link ResolvedType#getErasedType()}.
 * </p>
 * @param <T> The type of value represented.
 * @author Garret Wilson
 * @see ResolvedType
 */
public class TypeInfo<T> {

	/** The shared singleton instance of the ClassMate type resolver. */
	public static final TypeResolver TYPE_RESOLVER = new TypeResolver();

	private final ResolvedType resolvedType;

	/** @return The resolved type. */
	public ResolvedType getResolvedType() {
		return resolvedType;
	}

	/** @return The original type with runtime generics information erased. */
	@SuppressWarnings("unchecked")
	public Class<T> getErasedType() {
		return (Class<T>)getResolvedType().getErasedType();
	}

…

One thing I'm noticing now though (it was a long time ago) is that my type T seems to be in terms of the erased type. But I think that was still valuable in the actual usage. I'll have to see once I get deeper back into the code.

You can see that all these ideas (a generic type T indicating the original type, the ability to produce/reconstruct the original Type, etc.) were things we had been discussing here and there in these tickets. The LLM conversation and summary just provided me an opportunity to unify my thoughts.

I'm going to go ahead and implement something like a ResolvedType<T> (with a different name) in my database abstraction library and see how it goes. I'll design it with the goal of eventually bringing it back into PLOOP or a similar library. I'll let you know how it turns out. If you later want to collaborate on some Big Redesign of ClassMate, let me know.

Happy Holidays!

[cowtowncoder]

Even if you do not decide to go in a large-scale refactoring, I thought you might be interested in this synthesis and proposal.

Absolutely!

On Records: LLM answer seems to assume ClassMate is only needed for resolving Type Variables, or for main type itself; or if Record itself is generic. None of this is needed: Record with field List<String> is much easier to handle with ClassMate (or similar abstraction) than java.lang.reflect.Type. So I really do not see much distinction b/w POJOs and Records.

Or maybe we just disagree in usefulness/value of java.lang.reflect.Type type hierarchy? To me it's a pain to use, best to do without (except for erased Class<?> which is necessary) so no code ever should use Type for anything -- all access should be using ResolvedType.
However, that leads to question of why ClassMate has no ResolvedRecordType -- and it's something that probably ought to be added, in v2 (since v1 is Java 8-based, still).

But I am more puzzled by TypeInfo<T> -- just class parameterization of Class<T> itself I see limited (... or no) value for it. But particularly for ResolvedType. This based on usage by Jackson which perhaps differs from your usage of PLOOP?
But basically, I've rarely (or never?) had a case where binding of T was available or useful for this case.
It is always something to cast away, not use. When resolving POJOs, types being resolved are mostly for properties (Fields, Setter parameter, Getter result value), unrelated to containing type.
So perhaps this is distinction between the "root type", outer-most type, where maybe type of thing being passed (Class<T>, TypeReference<T>) could be useful. And then secondary types (of Members) less so.

Then again, to see pros and cons, it'd be necessary to try it out, and apply consistently.

On possible ClassMate 2.x, it may seem silly, but for me big part really is knowing how to handle versioning.
My gut feeling is that Jackson-style "re-package" is actually way to go, given that most ClassMate usage is (I think) via other libraries, frameworks, not direct use by applications. Which basically complicates compatibility aspects (due to need for binary compatibility, constraints (or not) of having deps to both 1.x and 2.x).
But unlike Jackson, would probably not change com.fasterxml.classmate into tools.classmate but maybe rather com.fasterxml.classmate2 (more due to not needing to buy domain for Maven publishing etc).

[garretwilson]

On Records: LLM answer seems to assume ClassMate is only needed for resolving Type Variables, or for main type itself; or if Record itself is generic. None of this is needed: Record with field List<String> is much easier to handle with ClassMate (or similar abstraction) than java.lang.reflect.Type. So I really do not see much distinction b/w POJOs and Records.

I think we may be talking past either other here. In further conversation with the LLM, it's starting to seem to me that there are three aspects to ResolvedType:

• Recursive resolution of all TypeVariable<D> with ParameterizedType (and of course support of other Type implementations). The LLM really brought it home to me that this is the core "resolution" of ResolvedType. (If that's not correct, let me know.)
• A general interface (a façade really) for working with types. This is I believe what you mean above where you say it's easier to use ClassMate than the Java Type hierarchy.
• A means (a "bridge") for reconstructing some original Type—not because we enjoy working with Type, but because it's needed for interoperability with other APIs. (This is PR Draft: Issue #69 | Add ResolvedTypeMapper to convert ResolvedType into Type #103 .)

So yes we would like to work with some reimagined ResolvedType everywhere instead of the java.lang.reflect.Type hierarchy. My point is merely that if ResolvedType were an interface, in cases in which all there are no TypeVariable<D> and the original Type was already fully resolved, the factory would simply provide a lightweight wrapper around the original Type. Yes an application would work with ResolvedType instead of Type, but internally this implementation wouldn't have to carry all the baggage that ResolvedType does now. For example your current ResolvedType.getTypeParameters() would delegate directly to …

💡(light bulb moment)

Oh, I see. ResolvedType.getTypeParameters() returns List<ResolvedType>. You're saying that you see a value in ResolvedType exposing the entire hierarchy as a parallel tree of ResolvedType, not just a full resolution of the Type tree by replacing all TypeVariable<D> with ParameterizedType. So even this lightweight Type wrapper (implementing a ResolvedType interface) would still return List<Type> if it simply delegated to e.g. ParameterizedType.getActualTypeArguments().

But wait, would a caller always want to walk the entire ResolvedType tree? If the Type is already resolved, then when it gets turned into a ResolvedType is an implementation detail. So for a Type tree that was already resolved (which is quite often I would assume!), the lightweight implementation of ResolvedType.getTypeParameters() could still return List<ResolvedType>—it could simply in turn wrap ParameterizedType.getActualTypeArguments() in ResolvedType.ofAlreadyResolvedType(Type) for example. It could do this each time (like Optional.of()) or lazily cache them. Something like Stream.of(ParameterizedType.getActualTypeArguments()).map(ResolvedType::ofAlreadyResolvedType).toList() comes to mind.

Actually I see that the LLM was even ahead of me on this point! Literally minutes before you responded above, it had mapped out what this interface would look like (calling it TypeInfo<>), and here is what it showed for getting type arguments:

    /// Returns the resolved type arguments, if any.
    ///
    /// For `List<String>`, returns `[TypeInfo<String>]`.
    /// For non-parameterized types like `String`, returns an empty list.
    ///
    /// @return Immutable list of type arguments; empty for non-parameterized types.
    List<TypeInfo<?>> typeArguments();

So yes, we are all considering a new ResolvedType to be a full replacement for Type with a better interface, and for the whole tree (the LLM "understood" that part before I did).

In conclusion I think I finally see why you were emphasizing that ResolvedType would always be useful to fully replace Type for the full hierarchy; that was something I overlooked before. And that's a good point, but I don't think it negates the benefit of having ResolvedType be an interface, and in some ways actually supports it!

Thanks for pointing out that subtlety. I'm literally right now in the middle of implementing this re-envisioned ResolvedType as an interface, so I'll see how it turns out.

On possible ClassMate 2.x, it may seem silly, but for me big part really is knowing how to handle versioning.

My proposal was a no-holds-barred brainstorming look at what would be possible with a redesign, so if you ever go in that direction, I would expect it to be a brand new ClassMate major version in the very least.

[cowtowncoder]

In conclusion I think I finally see why you were emphasizing that ResolvedType would always be useful to fully replace Type for the full hierarchy; that was something I overlooked before. And that's a good point, but I don't think it negates the benefit of having ResolvedType be an interface, and in some ways actually supports it!

Ah. This does explain why it did feel like we were talking past each other!

And just to make sure: I am not really against ResolvedType being interface -- esp. when there's clear need.

Also 100% agree with JDK Type convertibility being valuable for inter-operability.
Slightly skeptical of feasibility of sort of hybrid/lazy resolution, mostly due to likely complexity of making things work on-demand, but that's also not something to immediately rule out/rule in.

[garretwilson]

Literally seconds before your last response, my LLM put out the first version (after days of discussing and planning) of this re-envisioned ResolvedType. I'm getting ready to take a break for the day, and I haven't fully reviewed everything (especially the part about wildcards), but it's looking beautiful and I want to show it to you to illustrate the elegance of what this ticket proposes, in particular the interface aspect.

Here an extract from TypeInfo<T> (which would be the new ResolvedType I'm proposing):

  /// Creates type info for a simple class.
  ///
  /// @param <T> The type.
  /// @param type The class.
  /// @return Type info for the class.
  static <T> TypeInfo<T> of(final Class<T> type) {
    requireNonNull(type);
    return new SimpleTypeInfo<>(type);
  }

  /// Creates type info from a reflection `Type` that is already fully resolved.
  ///
  /// @param type The type (must not contain unresolved type variables).
  /// @return Type info for the type.
  /// @throws IllegalArgumentException if the type contains unresolved type variables.
  static TypeInfo<?> of(final Type type) {
    return createTypeInfo(type, null);
  }

  /// Creates type info from a reflection `Type`, resolving type variables using the given context.
  ///
  /// @param type The type to wrap.
  /// @param contextClass The class providing context for resolving type variables.
  /// @return Type info for the resolved type.
  /// @throws IllegalArgumentException if type variables cannot be resolved.
  static TypeInfo<?> of(final Type type, final Class<?> contextClass) {
    requireNonNull(contextClass);
    return createTypeInfo(type, contextClass);
  }

  /// Internal factory implementation.
  /// @param type The type to wrap.
  /// @param contextClass The context class for resolution, or `null` if not provided.
  /// @return Type info for the type.
  private static TypeInfo<?> createTypeInfo(final Type type, final @Nullable Class<?> contextClass) {
    requireNonNull(type);
    if (type instanceof Class<?> clazz) {
      @SuppressWarnings("unchecked")
      final TypeInfo<?> result = new SimpleTypeInfo<>((Class<Object>) clazz);
      return result;
    }
    if (type instanceof ParameterizedType parameterized) {
      return new ParameterizedTypeInfo<>(parameterized);
    }
    if (type instanceof GenericArrayType genericArray) {
      throw new IllegalArgumentException("GenericArrayType not yet supported: `%s`.".formatted(type.getTypeName()));
    }
    if (type instanceof TypeVariable<?>) {
      // ClassMate integration point: use contextClass to resolve
      throw new UnsupportedOperationException(
          "Unresolved type variable `%s`; ClassMate resolution not yet implemented.".formatted(type.getTypeName()));
    }
    if (type instanceof WildcardType wildcard) {
      // Resolve wildcards to their upper bound (usually Object for `?`)
      final Type[] upperBounds = wildcard.getUpperBounds();
      if (upperBounds.length > 0) {
        return createTypeInfo(upperBounds[0], contextClass);
      }
      return new SimpleTypeInfo<>(Object.class);
    }
    throw new IllegalArgumentException("Unsupported type: `%s`.".formatted(type.getTypeName()));
  }

If we're just getting TypeInfo<> for a raw class, it returns new SimpleTypeInfo<>((Class<Object>) clazz). I'm sure can guess how SimpleTypeInfo is implemented:

  @Override
  public Class<T> rawClass() {
    return rawClass;
  }

  @Override
  public List<TypeInfo<?>> typeArguments() {
    return List.of();
  }

  @Override
  public Type toType() {
    return rawClass;
  }

Where it gets interesting is in a type like List<String>. It returns new ParameterizedTypeInfo<>(parameterized), the constructor of which just wraps lightweight wrappers around each generic type:

  ParameterizedTypeInfo(final ParameterizedType parameterizedType) {
    this.parameterizedType = requireNonNull(parameterizedType);
    // (Note: I think we can skip saving a copy of the raw class here; that's something to review with the LLM.)
    this.rawClass = (Class<T>) parameterizedType.getRawType();
    // (Note: We could lazily create these if we wanted.)
    this.typeArguments = stream(parameterizedType.getActualTypeArguments())
        .<TypeInfo<?>>map(TypeInfo::of)
        .toList();
  }

  @Override
  public Class<T> rawClass() {
    return rawClass;
  }

  @Override
  public List<TypeInfo<?>> typeArguments() {
    return typeArguments;
  }

  @Override
  public Type toType() {
    return parameterizedType;
  }

In a non-genericized record (which is going to be 100% of the data we support right now, and I imagine the most frequent thing you'll see in real life—as far as record goes anyway), the recursive TypeInfo::of simply winds up returning SimpleTypeInfo instances for the generic types! So we get a fully tree of TypeInfo replacement for Type, that works for probably the majority of data in the wild, without even touching ClassMate resolution!!

But what happens if we have a record Wrapper<T>(List<T> items) {} and we try this with the List<T> items where we do need ClassMate resolution? (This is I think the objection you raised above the incorrect blanket statement that a record never needs its field types resolved.) The first createTypeInfo() level returns a ParameterizedTypeInfo as before, but when wrapping the parameterized type arguments the second level hits the TypeVariable and inside createTypeInfo() throws UnsupportedOperationException, as you see above. And that's all we need for now.

The long-term solution is that ClassMate would adopt this overall approach, and inside createTypeInfo() it would use its TypeResolver logic to resolve the tree just as we are doing, resolving and wrapping the types in TypeInfo.

But for the medium-term, when I need generic records or full generic object support, I'll simply implement a ResolvedTypeInfo that implements TypeInfo by wrapping the current ClassMate ResolvedType, providing lightweight wrappers around its hierarchy of ResolvedType instances. It won't be quite as efficient or lightweight as the long-term solution; that's why it's a medium term solution. But for the short term I don't even need genericized record support in the first place, so I don't even have to touch ClassMate at all! The beauty of all this is that this generalized interface allows me to plug in type resolution via ClassMate or even something else later and everything will just magically continue working behind the TypeInfo<> abstraction layer, without the caller knowing or caring.