potential support for customize gson

[kaibocai]

Issue describing the changes in this PR

A primitive implementation for support customizing gson instance used in java worker.
Issues opened on hard code gson instance are many: #682, #424, #419, Azure/azure-functions-host#7391, etc.

So maybe it's good to add flexibility supporting customer customize their gson instance.
Another solution would be work with Azure java sdk team on moving out of gson with better choice.
Board link: https://msazure.visualstudio.com/Antares/_boards/board/t/Functions%20Java/Backlog%20items/?workitem=17209424

SPI requirement: Azure/azure-functions-java-additions#20

This feature may not be needed at all, as most customer can using plan String and customize their gson instance inside their function to deserialize.

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)

Additional information

Additional PR information

[liliankasem]

This feature may not be needed at all, as most customer can using plan String and customize their gson instance inside their function to deserialize.

Customers can just bind to string and do their own deserialization, but I feel that this breaks the POJO scenario. When binding to a POJO, we should be able to handle that properly or allow for customers to customize gson as suggested here. This will avoid exceptions when deserializing something like Date

[2023-02-16T00:31:00.253Z] Exception: IllegalArgumentException: No time zone indicator
[2023-02-16T00:31:00.253Z] Stack: com.google.gson.JsonSyntaxException: Failed parsing '0001-01-01T00:00:00' as Date; at path $.ScheduleStatus

I think we should avoid guiding customers to use string binding when we can't deserialize their payload because of something like a date format, that's more an issue with us than with their code.

[liliankasem]

This feature may not be needed at all, as most customer can using plan String and customize their gson instance inside their function to deserialize.

Customers can just bind to string and do their own deserialization, but I feel that this breaks the POJO scenario. When binding to a POJO, we should be able to handle that properly or allow for customers to customize gson as suggested here. This will avoid exceptions when deserializing something like Date

[2023-02-16T00:31:00.253Z] Exception: IllegalArgumentException: No time zone indicator
[2023-02-16T00:31:00.253Z] Stack: com.google.gson.JsonSyntaxException: Failed parsing '0001-01-01T00:00:00' as Date; at path $.ScheduleStatus

I think we should avoid guiding customers to use string binding when we can't deserialize their payload because of something like a date format, that's more an issue with us than with their code.

@kaibocai The PR to fix the default DateTime for the timer info has been merged and should be released within the next month or so. However, I would still recommend this support for custom gson builder to avoid issues like this with other types and to provide user's more flexibility.

[kaibocai]

@kaibocai The PR to fix the default DateTime for the timer info has been merged and should be released within the next month or so. However, I would still recommend this support for custom gson builder to avoid issues like this with other types and to provide user's more flexibility.

yes, we definitely need to provide flexibility to customize serializing and deserializing.

[kaibocai]

No need to add sync block here, it's already thread safe with the sync block at

azure-functions-java-worker/src/main/java/com/microsoft/azure/functions/worker/broker/JavaFunctionBroker.java

Line 69 in 6725897

synchronized (oneTimeLogicInitializationLock) {

[shreyas-gopalakrishna]

Issues - #720