Hey, as Moshi is a successor to Gson and all the f...

# chucker

[Hitanshu Dhawan]

Hey, as Moshi is a successor to Gson and all the future developments will be done on Moshi instead of Gson. It’s a good time to migrate.
It also has benefits like lower size, Kotlin support etc.

I have migrated the code base from Gson to Moshi. Please have a look.
https://github.com/ChuckerTeam/chucker/pull/272

Do let me know if any changes/improvements are required 🙂

[Vova Buberenko]

Hi Hitanshu. Thanks for your contribution. We are aware of Moshi, as most of other devs in the community. But let’s not put such loud subjective opinions like all 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]

Hi Volodymyr. Thanks for going through this PR.

Agreed, we should consider migrating to Moshi after proper benchmarking.
After reading your discussions on GitHub, it seems like you are in for Moshi as it is performing better for Chucker case.

Also, this is my first PR so please don’t mind for any rookie mistakes.
So, should I go ahead and resolve all the discussions on the PR? Are we in for Moshi?

[Vova Buberenko]

Hey there.
Sorry if my feedback seemed too harsh.

As to PR - yeah, we should proceed with it. We would have to switch anyway, I believe. So let's be preparedfor it.
Just resolve some core issues, like adding Roboelectric, etc.

I will get back with more feedback for PR when I get to my laptop in a few hours.

[Hitanshu Dhawan]

Hi Volodymyr. I have resolved all the discussions and done all the changes required.
Please have a look whenever possible and let me know if any further changes is required.
Thanks.

[Hitanshu Dhawan]

Hi Volodymyr. I have fixed all the new changes required.
Do have a look whenever possible. Thanks.

[Hitanshu Dhawan]

Hello @Vova Buberenko.
This is regarding the PR raised by me for migrating Gson to Moshi.

I have a small question for you.
In chucker there is a type adapter added to GsonBuilder 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]

Hi.
As you your question about why this adapter existed - I don’t know, since it was long before I joined the team. But I looked carefully at the code and have to admit that your point is correct and we don’t actually need this DateJsonAdapter 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.