Enhance message system with StaticType #1289
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR enhances the messaging system with the new
StaticType
class. It allowssendBlocking()
return values to be deserialized to the expected return type, simultaneously type-checking the return value. An example:Currently, to call a remote method and get the return value you would do something like this:
Assuming
getServiceList()
returned the expected list, this would work just fine thanks to the virtual class field embedded in the JSON. However, if this method changed to return a list ofServiceInterface
or something, this would still succeed since casting can't check generics at runtime. It would only blow up upon accessing the list, with aClassCastException
, potentially several message hops away.Now, one would do this:
Note the lack of a cast and the new
StaticType
parameter. This "reifies" the expected return type, allowing it to be accessed at runtime. It is then accessed byCodecUtils
when deserializing a message, informing the deserializer of the requested type. If the object is not of the expected return type (or an allowed alternative like a subclass), then the deserialization fails. This ensures we don't pass bad data around before crashing with a hard-to-debugClassCastException
Fixes #1226
NOTE:
This does not work for return types with non-concrete generic parameters. For example:
This will fail even if T is defined by a class or method generic parameter. This is because StaticType cannot reify non-concrete generic type parameters even if they are defined somewhere else.
I also do not know how wildcards will function with this. For example:
This may or may not fail, but if it does fail, it will do so during construction of the StaticType. More testing is needed for this.