[FeatureRequest] Allow customizing the Gson instance for Json serialization

[CrawX]

Hi all,

Current problem
The Gson instance used by RpcUnspecifiedDataTarget is hardcoded in RpcJsonDataSource

azure-functions-java-worker/src/main/java/com/microsoft/azure/functions/worker/binding/RpcUnspecifiedDataTarget.java

Line 68 in 3ec27b2

dataBuilder.setJson(RpcJsonDataSource.gson.toJson(value));

azure-functions-java-worker/src/main/java/com/microsoft/azure/functions/worker/binding/RpcJsonDataSource.java

Line 20 in 3ec27b2

public static final Gson gson = new Gson();

This means that customizing the way the runtime Json-serializes objects (especially dates) is impossible. See #419 and this on stackoverflow.

Workaround
I came up with a dirty workaround to replace the used Gson instance with the spring-provided one via Reflection:

AzureGsonConfig.java:

@Configuration
@ConditionalOnClass(RpcJsonDataSource.class)
public class AzureGsonConfig {

  @SneakyThrows
  public AzureGsonConfig(Gson gson) {
    final Field gsonField = RpcJsonDataSource.class.getField("gson");
    gsonField.setAccessible(true);
    final Field modifiersField = Field.class.getDeclaredField("modifiers");
    modifiersField.setAccessible(true);
    modifiersField.setInt(gsonField, gsonField.getModifiers() & ~Modifier.FINAL);

    gsonField.set(null, gson);
  }
}

This requires a compile-time dependency like this

compileOnly files('libs/azure-functions-java-worker.jar')

(referencing the runtime as a jar file because I couldn't find it in maven central).

Having replaced the Gson instance means you can have a second configuration that customizes the date serialization behaviour of the one from spring.

GsonConfig.java:

@Configuration
public class GsonConfig {

  @Bean
  GsonBuilderCustomizer dateFormatGsonBuilderCustomizer() {
    return gsonBuilder -> {
      gsonBuilder.registerTypeAdapter(
          LocalDate.class, new LocalDateAdapter()
      );
      gsonBuilder.registerTypeAdapter(
          LocalDateTime.class, new LocalDateTimeAdapter()
      );
    };
  }

  static class LocalDateAdapter extends TypeAdapter<LocalDate> {

    @Override
    public void write(final JsonWriter jsonWriter, final LocalDate localDate) throws IOException {
      if (localDate == null) {
        jsonWriter.nullValue();
      } else {
        jsonWriter.value(localDate.toString());
      }
    }

    @Override
    public LocalDate read(final JsonReader jsonReader) throws IOException {
      if (jsonReader.peek() == JsonToken.NULL) {
        jsonReader.nextNull();
        return null;
      } else {
        return LocalDate.parse(jsonReader.nextString());
      }
    }
  }

  static class LocalDateTimeAdapter extends TypeAdapter<LocalDateTime> {

    @Override
    public void write(final JsonWriter jsonWriter, final LocalDateTime localDateTime) throws IOException {
      if (localDateTime == null) {
        jsonWriter.nullValue();
      } else {
        jsonWriter.value(localDateTime.toString());
      }
    }

    @Override
    public LocalDateTime read(final JsonReader jsonReader) throws IOException {
      if (jsonReader.peek() == JsonToken.NULL) {
        jsonReader.nextNull();
        return null;
      } else {
        return LocalDateTime.parse(jsonReader.nextString());
      }
    }
  }
}

While this works, it's not very clean and can break easily.

Alternative
Serialize the objects to strings in the functions or handlers and return them as such. Personally, I don't like this approach.

Feature request
Somehow allow injecting or customizing the Gson instance used in the azure-functions-worker runtime.

[vetler]

+1

[kaibocai]

Hi Johannes (@CrawX) , Vetle Leinonen-Roeim (@vetler) , thanks for opening this issue. This is a hard issue we are actively working on. We are trying to remove gson dependency from java worker. We will try to roll out the feature as soon as possible. Will keep you updated. Thank you.

[CrawX]

Unfortunately, using the workaround that I posted is getting significantly more complicated with JDK12 and higher.
With JDK17 being GA with Azure functions, this is the only thing keeping me from switching to JDK17.

Is there an update on when this could be fixed?

[kaibocai]

Hi Johannes (@CrawX), thanks for raising the issue for request this feature. I am trying to see how much benefit this feature will bring to our user.
So you can always bind the payload to a plain String type and customize your gson instance in the function app to deserializeyour playload right. This won't have much difference compared with we providing a hook for user to customize their gson instance. Correct me if I understand it wrongly. Thanks.

[CrawX]

I don't consider using a String to be a viable alternative. If you use this with Spring Boot, it feels very awkward and not how you would expect Spring to behave at all.

Using a String directly would require all individual users either implement the necessary boilerplate code for serialization themselves, either as a generic abstraction or in each function. The first option causes a lot of room for error and duplication amongst users, the second one feels very awkward.

The fact that this is not configurable right now seems to be more a implementation detail / limitation than a conscious design decision.