Address variance in type resolution between v3 and v4


The serialization framework resolves wildcard types and type variables to their upper bounds, and attempts to resolve type variables based on the context in which they appear. It makes extensive use of Guava's TypeToken to do this.

Both v3 and v4 will resolve the type variable C in this context to Comparable<*>:

However, v3 and v4 will give different resolutions for C as the type of Example.value in this context:

v3 will resolve C to Any (the upper bound of the type variable in the superclass), while v4 will resolve it to Comparable<*>.

This is almost never a problem, except that QueryCriteraUtils includes the following:

In a serialisation context (e.g. RPC) in which Comparable is not whitelisted, v4 was refusing to serialize a ColumnPredicate.BinaryComparison, while the class passed v3's whitelist checking due to Comparable effectively being resolved out of its understanding of C as the type of BinaryComparison.rightLiteral.

We worked around this problem by quietly exempting Comparable from whitelist checking, without actually adding it to the default whitelist (since that would cause it to be mentioned in the AMQP schemas of many messages where it was previously ignored, since the whitelist also controls which types are written into the schema and included when calculating the fingerprint/type descriptor of each type, which in turn is used to determine whether evolution might need to occur). However, we only did this for Comparable, to fix the specific exception that occurred when trying to serialize vault queries involving BinaryComparison over RPC.

There may be a wider class of issues caused by this variance between v3 and v4's type resolution behaviour. We would see a similar error occurring if customer code includes an interface other than Comparable that:

1) was used as the upper bound of a type variable, e.g. C extends CustomerInterface,
2 in a context where that same variable was used as a type parameter in the superclass, without the type bound, and
3) was not included in the customer's CorDapp whitelist.

This is a very unusual set of circumstances, and it may be that the simplest resolution in most cases would be to instruct the customer to include the offending interface in their CorDapp whitelist. However, we should consider whether a more systematic fix should be attempted, for example either

a) Changing v4's type resolution behaviour to match v3's exactly, or
b) Adding a mechanism to configure a list of interfaces which can be "silently" whitelisted without being added to the official whitelist (and thus written into the AMQP schema for messages, etc)

My view is that we should do neither of these things, and it will probably be all right; but we should make a clear decision either way.






Epic Link




Engineering Teams


Fix versions

Affects versions

Ported to...


Story Points / Dev Days


Build cut