Describe the bug
An edge case exists in the virtual class field deserialization routine,
where data intending to be deserialized as an array will instead be deserialized to
an ArrayList because there exists no type information to determine the representation
to use. For most cases, the method cache will be available to use for this type information,
but when using Service.sendBlocking() the callback method usually does not exist and therefore
no type information is available. An example use case where this would be a problem is when
calling a remote method using sendBlocking() that has an array return type.

Recommended Solution
The solution I recommend is adding a similar functionality as Service.blockingList to CodecUtils
that contains the type information for an expected message. The entries for this map will be set by Service.sendBlocking() just like the blockingList map. When CodecUtils.jsonToMessage() (from #1211) is called, it will check this map to see if the type information is available, and if so will pass it to the deserialization routines before removing it from the map (to avoid memory leaks, the type information shouldn't change otherwise). This will stop this edge case from being triggered by Service.sendBlocking() which is the only instance I know of.