I'd like more flexibility in Gdx.Json field type logic

Description

Take kotlin value classes - I can customize a Gdx Json to (de)serialize them as I want them, but that only works for instances inside a collection. Instances that are direct members of a container class are always (de)serialized as their internal value class, so I cannot migrate to such a class maintaining serialization compatibility.

Additional Information

Now, to an extent Gdx is entirely innocent, Java reflection does see such field as a primitive, my value class was erased. But I could work around that - e.g. by defining a @SerializeAs(type: KClass<*>) - if at any of the customization hooks[^1] I still had access to the reflection field. Now if OrderedMap<String, FieldMetadata> getFields (Class type) were overrideable and I could subclass FieldMetadata, that would be an avenue, but both are walled off.

So - Gdx itself could easily offer such an annotation (pardon my wild guess as non-Java-expert). FieldMetadata constructor could look for it and remember the type given, and so on. Alternately, an overrideable function Class resolveType(Field field) that is called by getFields and records the type in the metadata... If one were to also pass the container object reference to that, it could be even more flexible - but an annotation is more readable.

[^1]: setSerializer, or override writeValue/readValue. Serializable is too limited - no constructor control and cannot do non-{}-wrapped representations. Always infuriating when one runs into that limitation.