kubernetes-client: Stack overflow on multi maps (and other non-trivial generic classes)

Describe the bug

Hi,

while I was testing my other work (#4354) against Keycloak operator schema, I noticed another issue. The schema generation fails with StackOverflowError.

Upon closer inspection, it looks that the problematic part is their usage of concrete multi maps like so:

private MultivaluedHashMap<String, ComponentExportRepresentation> components;

public class MultivaluedHashMap<K, V> extends HashMap<K, List<V>> { /* ...  */ }

Fabric8 Kubernetes Client version

6.0.0

Steps to reproduce

Here’s a minimal failing example:

@Group("map.fabric8.io")
@Version("v1alpha1")
public class ContainingMaps extends  CustomResource<ContainingMapsSpec, Void> {}

public class ContainingMapsSpec {
  private MyMultiMap<String, String> test3;
}

public class MyMultiMap<K, V> extends HashMap<K, List<V>> {}

Unfortunately, this cannot be avoided by using @SchemaFrom or @SchemaSwap annotations, because the Stack Overflow happens an a code path that does not process these annotations, namely in AnnotatedPropertyPathDetector

And it is not even necessary to run the full schema generation.

All that is needed to trigger the Stack Overflow (i.e. from a unit test) is:

Types.typeDefFrom(MyMultiMap.class);

Expected behavior

The problem is in the unschallow logic, implemented in Types class.

For generic types, the methods projectSuperClasses, projectDefinition, mapClassRefArguments and mapGenericProperties replace type parameters on superclasses with their concrete instantiations from usage site.

For simple types, like class IntStringMap extends HashMap<Integer,String>, this works by first creating a mapping {K -> Integer, V -> String} and thein recursively replacing all usages of K and V according to the mapping.

However, in our case, the mapping contains V -> List<V>. This gets expanded infinitely to List<List<List<...>>>, until memory is exhausted.

Obviously, expected behavior is for this to not happen, the V should only be expanded once.

Runtime

other (please specify in additional context)

Kubernetes API Server version

other (please specify in additional context)

Environment

other (please specify in additional context)

Fabric8 Kubernetes Client Logs

No response

Additional context

I think I may have a fix for the StackOverflowError, we can discuss that further, just please confirm that somebody else is not working on it already.

As a side note, even with that fixed, multimaps are still generated wrong. I may have a cure for that, too, but I’d create a separate issue.