Hitanshu Dhawan
03/11/2020, 6:40 AMVova Buberenko
03/11/2020, 9:13 AMall the future developments will be done
or successor to Gson
. Those are just opinions of some persons and we will still see projects with Gson till Google decides to drop it. In case of your message here or PR description is sounds in a manipulative manner, which I would prefer to avoid.
As to Good time to migrate
- we already discussed that we will look into alternatives to Gson in future in some PRs, but it is not a priority at the moment. Moreover, despite using Moshi in some of projects I work on I would like to have a justification for such move. For this purpose I am going to do some benchmarking considering particular Chucker use cases (would like to emphasise that I am not talking about general case benchmarks, which can be found in multiple articles, so let’s not discuss the results from such articles here).
Before that I am against merging this PR, because it is just a PR for the sake of PR with the description being compiled of multiple opinions of other people instead of your own.
Thanks for your understanding.Hitanshu Dhawan
03/11/2020, 1:41 PMVova Buberenko
03/11/2020, 3:20 PMHitanshu Dhawan
03/12/2020, 9:54 AMGsonBuilder
for parsing dates.
.registerTypeAdapter(Date::class.java, DateTypeAdapter())
But, we are using Gson to only serialize and deserialize List<HttpHeader>
.
There is nowhere in the code where we are serialize and deserialize Date
.
So, my question is why is there a type adapter added for Date when we are not serialize and deserialize Date
in the code base, do we really need a date adapter?
If it’s not needed, should I also remove my custom DateJsonAdapter
and its related test cases in my PR?
Thanks for your cooperation.Vova Buberenko
03/17/2020, 10:19 AMDateJsonAdapter
for our current purposes.
So feel free to remove it along with tests for date parsing, since it seems we aren’t parsing dates there.