Resolve forwarded type arguments across POJO hierarchy edges

[vbabanin]

Problem

After JAVA-3815, encoding a POJO that uses the following hierarchy shape fails:

public abstract class AbstractModel<V> implements InterfaceModel<V> {
    private V value;
    public V getValue() { return value; }
    public void setValue(V v) { this.value = v; }
}

public class ConcreteModel extends AbstractModel<Map<String, Object>> {}

Encoding a ConcreteModel instance throws:

CodecConfigurationException: Can't find a codec for class java.lang.Object

The value property - which should resolve to Map<String, Object> - is being resolved to Object instead.

Root cause

The underlying problem - cachePropertyTypeData unconditionally overwriting a property's resolution on later visits - already existed with superclass chains (JAVA-5110). Same root cause, different symptom: there, a forwarding chain like C extends B<String>, B<T> extends A<T>, A<K> resolves K to Object because the TypeVariable is never substituted. Users with that shape have been hitting it since at least 2023.

JAVA-3815 added interface scanning, which exposed the same overwrite problem for a new set of users: because AbstractModel<V> implements InterfaceModel<V>, the same property is now visited twice - first from AbstractModel with the correct concrete TypeData, then from InterfaceModel with stale TypeData. The second visit silently overwrote the first, surfacing the regression for users who had never changed their code.

Walk trace for ConcreteModel:

Step	Class being added	parentClassTypeData passed
1	ConcreteModel	null (root)
2	AbstractModel	TypeData(ConcreteModel, [Map<String,Object>]) - correct
3	InterfaceModel (via AbstractModel's interfaces)	TypeData(AbstractModel) - no type params

When the walker scans InterfaceModel, it finds getValue() again and calls cachePropertyTypeData("value", ..., TypeData(AbstractModel)). This overwrites the correct resolution (Map<String,Object>) with TypeData(Object).

Fix

TypeData.newInstance - new composing overload that accepts the current class's type parameters and resolved TypeData as context. When a type argument in an extends/implements clause is a TypeVariable, it is substituted against that context rather than erased to Object. Nested ParameterizedType arguments (e.g. List<T>) are handled recursively.

PojoBuilderHelper.getClassHierarchy - both the superclass edge and per-interface edge now use the composing TypeData.newInstance, so TypeVariables in extends/implements clauses are substituted against the current class's resolved type arguments rather than erased to Object.

JAVA-6065
JAVA-5110
JAVA-6138

[rozza]

@vbabanin I shouldn't have pushed my changes here (reverted) I have created a PR for additions to this branch: vbabanin#2

Initial thoughts are this looks good and I prefer over #2015 as its much more robust.

[vbabanin]

Thank you, @rozza! I cherry-picked your suggested changes onto this branch.

[Copilot]

Pull request overview

Copilot reviewed 27 out of 27 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 27 out of 27 changed files in this pull request and generated no new comments.