Java runtime cast to generic interface without losing type information

I have a generic interface that can be implemented by different subclasses of an abstract base class.

interface PropertyOne<T> {
  T type();
  List<String> values();
}

In the base class I defined a small helper method that checks if the current instance implements that interface and cast to it if possible:

<T> Optional<T> toProperty(Class<T> clazz){
    if (clazz.isAssignableFrom(this.getClass())){
      return Optional.of(clazz.cast(this));
    }
    return Optional.empty();
}

I use this helper method for example to get and print those values:

void printValues() {
    List<String> values = toProperty(PropertyOne.class)
      .map(p -> p.values())
      .orElse(Collections.emptyList());
    System.out.println(values);
}

But this gives me a unsafe cast warning, since values() now returns a List instead of a List<String>. I know that the generic type information is lost after compiling the code, but since the return type of values is always a List of type String it should be safe anyway?

Using the following boilerplate code works without warnings.

if ( this instanceof PropertyOne<?>){
   List<String> vs = ((PropertyOne<?>)this).values();
   System.out.println(vs);
}

I can do a manual cast for the first variant as well like .map(p -> ((PropertyOne<?>)p).values()) to get rid of the warning but this again adds a lot of boilerplate.

So I got two questions:

1. Why is the List<String> type information lost in the first place?
2. Is it possible to dynamically cast to a wildcard/ unbounded type directly without manually doing a cast to PropertyOne<?> afterwards?

Because the generics on Class<T> are quite limited and cannot be used in this fashion (I'd say the generics on j.l.Class are broken, but that's perhaps a bit harsh. They also have some use, just.. not much). Generics can represent things that a class instance cannot; class instances (an instance of java.lang.Class can represent things that generics cannot. Specifically, List<String> cannot be expressed as a class instance, and int.class is a class instance that cannot be expressed in generics.

In other words, the moment you try to communicate a full generified type (such as PropertyOne<String>) in a java.lang.Class<T> instance, you lost the game - that T in j.l.Class can only ever be a generics-less type.

So, this is not how to do it.

your toProperty method has got to go. Not for the issues in this post; it's about trying to invoke type() on your PropertyOne instance derived from the (optional-wrapped) toProperty call.

Separate from that, the reason that you're running into trouble on your values() invocation, which seems to have no actual relevant generics parts to it, is because of archaic java rules: Once you go 'raw', EVERYTHING is raw, even the things that don't need it.

So, in toProperty(PropertyOne.class), that would end up returning an Optional<PropertyOne> - a raw type, because that's not okay; you'd need e.g. PropertyOne<?> which is different from PropertyOne (that last one is raw; the former is not) - but you can't do that with Class<T>, because Class<T> is broken. Now you're in raw territory, and invoking values() on this raw type will end up returning a raw list (just List), you'd think that still gives you a List<String> as the return type of values() is not dependent on the generics of PropertyOne but that's just not how it works, java lang spec says no.

There are a few ways out of this conundrum, but mostly you're just misusing generics here, you can't really do any of this. Remember, generics are a figment of the compiler's imagination: They do not exist at runtime whatsoever. There's no way to runtime check anything. Once you start mixing generics and runtime constructs such as instanceof or x.isAssignableFrom, it's never going to work out.

If you must, you may get there with something called 'Super Type Tokens' - you can google for that (toss in 'java' as a keyword), these CAN represent quite precisely anything you can stick inside generics. But that still sounds like a mistake; but I can't really tell you what you have to do here, your problem description is talking about a broken solution and not about the problem that your broken solution is trying to solve.