add java.lang.reflect.Type to deserialize API

[xiazuojie]

Describe the proposal

As discussed #293 , TypeRef<T> was added to support deserialization of generic types.
However, instances of TypeRef<T> can only be statically (during compilation) created. There are occasions when generic types need to be dynamically created. I suggest adding the following method to deserialize API to support such cases.
<T> T deserialize(byte[] data, java.lang.reflect.Type type) throws IOException

[artursouza]

Can you provide an example of a scenario that will not work with the current API?

BTW, this change is not only to the deserialize API, it will also propagate to every method in our API that invoke deserialize() internally. Today, users can also have their own serialization done outside the SDK and send byte[] as input - in those cases, the internal serialization is skipped.

[xiazuojie]

My scenario is that users' code relies on some other API that works with java.lang.reflect.Type. I need to translate it into Dapr's DaprObjectSerializer API.
With current implementation, it's not possible to do the translation - users' code has to rely on dapr-sdk directly, which is not desired.

[artursouza]

The default serializer uses java.lang.reflect.Type. See type.getType() in the implementation below. Is this what you need?

  public <T> T deserialize(byte[] content, TypeRef<T> type) throws IOException {
    return deserialize(content, OBJECT_MAPPER.constructType(type.getType()));
  }

[xiazuojie]

The default serializer uses java.lang.reflect.Type. See type.getType() in the implementation below. Is this what you need?

  public <T> T deserialize(byte[] content, TypeRef<T> type) throws IOException {
    return deserialize(content, OBJECT_MAPPER.constructType(type.getType()));
  }

Not what I want. I need the following api.
<T> T deserialize(byte[] data, java.lang.reflect.Type type) throws IOException

Note that one cannot create an instance of TypeRef<T> from java.lang.reflect.Type dynamically.

[artursouza]

All of the Dapr's Java SDK relies on Class or TypeRef. If your code relies on Type directly, it is not just the serializer but also all of the APIs in the SDK. We can add overloaded methods for Type everywhere or we can add a new method in TypeRef to do what you want. In this case, the generic type would be Object since there is no generic type in Type:

  public static TypeRef<Object> get(Type type) {
    return new TypeRef(type) {};
  }

This seems to provide a more concise API than giving two deserialize methods to be implemented by applications. When designing an API we need to be mindful not to make changes with only one app in mind, so I am trying to generalize your ask to keep the SDK relevant to other apps too.

[artursouza]

In summary: I am not in favor of adding an overloaded deserialize method with Type as input since it would impact all of the SDK APIs.

The same can be accomplished with adding the new builder method in TypeRef where type is given as input (like in the comment above). This way there is a way to convert between Type and TypeRef back and forth, allowing user code that relies on Type only to still make use of the Dapr SDK. This solution would also not be a breaking change.