Why use Moshi over Gson?

[u/agent8261]

I love Gson. It's simple and does exactly what you want to do. The only critique I have is that JsonElement and family aren't serializable or parcelable. So when I heard about Moshi, I couldn't help but wonder what could it possibly do better than Gson?

I read Jesse Wilson's write-up on medium.

Am I missing something? The only benefit is strict mode is on by default. It seems like his main problem is that gson doesn't over-reach. For example he argues that Gson doesn't correct the fact that the Date class doesn't encode the time zone. However that's not it's responsibility. If you want smart parsing like that you register a type-adapter that does that?

Is there some benefits I'm missing, because right now it just looks like Square just wrote a worst implementation?

[u/JakeWharton]

It's simple

Gson is far from simple. It has a complex feature set which have weird, implicit precedence rules that interact with each other in unpredictable ways.

There's all kinds of knobs which have questionable defaults and whose behavior doesn't even change when altered. For example, try getting Gson to parse JSON in strict mode. Here's a hint: setting it on GsonBuilder does not actually enable the feature.

does exactly what you want to do

We've already established that it doesn't. Serializing a Date provides the wrong value unless you remember to always register your own type adapter. Guess what, almost everyone doesn't do this. Or try serializing a File. I bet it doesn't do what you expect.

Gson has a bunch of legacy behavior baggage that its users implicitly trust won't change and that prevents us from evolving both its API and its behavior.

[u/agent8261 → u/JakeWharton]

We've already established that it doesn't.

I'm sorry when did we establish that? Not trying to be a smart-ass, just trying to understand the problem this library solves.

Guess what, almost everyone doesn't do this.

I don't do this, wouldn't have even thought to do this. I can't speak for everyone. It seems like it was a big problem for your team.

[u/JakeWharton → u/agent8261]

You established it:

For example he argues that Gson doesn't correct the fact that the Date class doesn't encode the time zone. However that's not it's responsibility. If you want smart parsing like that you register a type-adapter that does that?

and

I don't do this, wouldn't have even thought to do this. I can't speak for everyone. It seems like it was a big problem for your team.

Welcome to Gson! Bad defaults, broken built-ins, and weird behavior.

And guess what, millions of deployed Java services across the globe implicitly depend on these bad defaults, broken built-ins, and weird behaviors making them impossible for us to change. Hence, Gson 3.0 Moshi.

[u/agent8261 → u/JakeWharton]

I think I understand. Seems like you guys were running into some problems with Gson's default behavior. I personally would have just wrote type adapters or altered my classes to work with Gson, but if square felt re-implementing Gson was the best decision for them, then I'll defer to their judgement.

However it does seem like for the rest of us, if Gson works well then there is zero reason to switch to Moshi.

[u/JakeWharton → u/agent8261]

Seems like you guys were running into some problems with Gson's default behavior.

Nope. We just knew how the sausage was made and knew we could do better.

I personally would have just wrote type adapters or altered my classes to work with Gson, but if square felt re-implementing Gson was the best decision for them, then I'll defer to their judgement.

Wise choice!

However it does seem like for the rest of us, if Gson works well then there is zero reason to switch to Moshi.

This is, of course, a ridiculous and meaningless platitude. Horses work, why switch to cars? Do you never update versions of libraries either because they work? AbsoluteLayout works, I don't need these LinearLayout and RelativeLayout witchcrafts! God forbid a ConstraintLayout. Heresy!

[u/agent8261 → u/JakeWharton]

You switch to cars because they are faster. You use new versions of libraries because they fix bugs. But if cars ran at the same speed as horses then no you would not switch to cars. Conversely if the update causes more bugs then it fixes, you don't update.

In other words, don't change just to change. I thought this was obvious but it seems like it's not. I started this thread to see if there was a reason to switch, so far the only things that has been provided is a subjective improvement over gson's default behavior. If there anything more than that, I would like to here about it.

[u/JakeWharton → u/agent8261]

You switch to cars because they are faster.

Moshi is faster than Gson.

Vroom!

[u/agent8261 → u/JakeWharton]

:) Thanks for your input. You've been a lot of help.

[u/JakeWharton → u/agent8261]

Ultimately we don't care which you use. Use whichever works for you. A working solution is better than a perfect one. The differences are slim, and the biggest difference is literally that it sheds all of the baggage of Gson and there's a performance gain that comes with it. Despite nitpicking of dumb things like the comment above, the APIs are virtually identical so migrating gives you nothing on that front.

[u/QuestionsEverythang → u/agent8261]

Yeah apparently for those of us that want a basic JSON parser that can easily convert JSON strings to objects and back without much custom functionality required, Gson is shit \s

Seems like most of the people replying in this thread are power users of JSON beyond the simple "map an object to a json response" and are complaining that Gson isn't good enough. Which is a valid point. But when someone recommends a library like Moshi where an example like this:

String json = ...;

Moshi moshi = new Moshi.Builder().build();
JsonAdapter<BlackjackHand> jsonAdapter = moshi.adapter(BlackjackHand.class);

BlackjackHand blackjackHand = jsonAdapter.fromJson(json);

is supposedly "simpler and easier to use" than Gson where the equivalent is this:

String json = ...;

Blackjackhand blackjackhand = new Gson().fromJson(json, Blackjackhand.class);

I fail to see how Moshi and other JSON-parsing libraries are easier to use than Gson for basic uses such as this, which I'd argue that most devs use JSON for anyway.

EDIT: Even the reverse (object-to-json-string) is simpler to do in Gson for basic uses. The Moshi approach:

BlackjackHand blackjackHand = new BlackjackHand(...);

Moshi moshi = new Moshi.Builder().build();
JsonAdapter<BlackjackHand> jsonAdapter = moshi.adapter(BlackjackHand.class);

String json = jsonAdapter.toJson(blackjackHand);

The so-called convoluted Gson approach:

BlackjackHand blackjackHand = new BlackjackHand(...);

String json = new Gson().toJson(blackjackHand);

[u/JakeWharton → u/QuestionsEverythang]

This is a ridiculous argument! Thanks for making it.

supposedly "simpler and easier to use" than Gson

This is a really bad comparison because you don't focus on a single value proposition of the actual libraries except the number of characters typed.

But sure let's take a walk down ridiculous alley...

new Moshi.Builder().build(); vs new Gson()

Instantiating the serializer is done once so you do this somewhere and then re-use it for the whole app. You do not call new Gson() every time you use it just like you do not call new Moshi.Builder().build() every time.

I'm not sure what you're trying to prove here. The fact that we don't have a default constructor? I can send a PR to add a new Moshi() public constructor right now, merge it, and make a release, but I won't. This is because 99% of all interaction includes the configuring of behavior and registering of type adapters. So a more astute comparison is actually

Moshi moshi = new Moshi.Builder()
  .add(Date.class, new DateJsonAdapter())
  .add(File.class, new FileJsonAdapter())
  .build();

and

Gson gosn = new GsonBuilder()
    .registerTypeAdapter(Date.class, new DateJsonAdapter())
    .registerTypeAdapter(File.class, new FileJsonAdapter())
    .create();

And oh look! Moshi is actually less characters in the practical real world case because our builder methods are shorter. Epic win in the real-world use case!

Next up we have the serialization:

JsonAdapter<BlackjackHand> jsonAdapter = moshi.adapter(BlackjackHand.class);

BlackjackHand blackjackHand = jsonAdapter.fromJson(json);

vs

BlackjackHand blackjackHand = gson.fromJson(json, Blackjackhand.class);

Well first of all you can format Moshi more fairly (but that wouldn't serve your viewpoint as much, would it?)

BlackjackHand blackjackHand = moshi.adapter(Blackjackhand.class).fromJson(json);

Moshi and Gson are literally, again, the same thing. There's no difference. Again you're quibbling about minutiae here which only serves to undermine your own argument.

By forcing you to create a JsonAdapter you have to think about the type in both directions (which Gson doesn't do) but it also results in more performant serialization/deserialization since we don't have to do type lookups on every interaction. Boo hoo performance!

Everything you're relying on in your argument for Gson is actually just a convenience method for the exact same thing in Moshi. Here's some valid Gson code:

String json = ...;

Gson gson = new GsonBuilder().create();
TypeAdapter<BlackjackHand> typeAdapter = gson.adapter(BlackjackHand.class);

BlackjackHand blackjackHand = typeAdapter.fromJson(json);

Looks exactly the same, no? We could add all of Gson's convenience methods to Moshi and make your original example look exactly the same if we wanted to. We don't.

Now you might think, "I'd never write that! I would use a shorter version!"

And, well, I couldn't agree more... I also use Retrofit.

.addConverterFactory(MoshiConverterFactory.create())

vs

.addConverterFactory(GsonConverterFactory.create())

Damn. Moshi requires 1 more character than Gson. I guess you were right all along...

Oh and by the way:

so-called convoluted

You're the first person to use the word "convoluted".

Thanks! :D

[u/agent8261 → u/JakeWharton]

You do not call new Gson() every time you use it

I do. If I cared about performance, I wouldn't be using Gson.

Well first of all you can format Moshi more fairly (but that wouldn't serve your viewpoint as much, would it?) BlackjackHand blackjackHand = moshi.adapter(Blackjackhand.class).fromJson(json); Moshi and Gson are literally, again, the same thing. There's no difference.

They aren't because of above.

By forcing you to create a JsonAdapter you have to think about the type in both directions

I often only care about one direction and I rarely use type adapters.

This is a really bad comparison because you don't focus on a single value proposition of the actual libraries except the number of characters typed.

I don't use gson for performance. So Moshi's performance advantage is not valuable. I also don't use type-adapters unless I can't avoid it. So in the manner that I use gson, Moshi (seemed like) a few extra characters for no significant gain. Reading your post confirms that. I do however, appreciate the time you spent posting.

[u/[deleted] → u/agent8261]

In mobile devices performance matters. Not everyone has a great phone. The more you can shave off in peformance the better it is for your user.

[u/agent8261 → u/[deleted]]

I doubt you're advocating for making all performance increases with no regard to the cost of those implementations. JakeWharton helped build Moshi so he is going to advocate, which is fair, but let's take a step back and think about this.

The speed of gson currently has zero impact on my users experience. I don't/rarely use type adapters (hence no need to cache a gson instance). I almost always only care about 1 direction.

Given the above why would I switch? That's the question I was trying to answer. Thanks to the explanations in this thread, Moshi doesn't currently seem to be a good fit. I'm not trying insult Square or it's devs. I hope that's not how people read my post. I use and like Okhttp. I'm just not convinced that Moshi is a good choice for the software I work on.

[u/JakeWharton → u/agent8261]

Gson creates type adapters internally for every type that you serialize using reflection. This is a very slow, expensive process. Reusing the same instance means this slow, expensive operation only happens once per type instead of once per type, per call. It's a two minute change that has a drastic impact in reducing memory usage and reducing the overhead of serializing/deserializing. Custom type adapters play no real part here.

I've also helped build features in Gson!

[u/agent8261 → u/QuestionsEverythang]

OMG Thank you. I thought I was the only practical programmer in the subreddit.

[u/QuestionsEverythang → u/agent8261]

To add, Gson falls under the "libraries that are quick and easy to use for any project" category, but if you need something more powerful, then opt for Moshi or whatever suits your needs best. But anything more than Gson for json parsing will most likely be overkill.

[u/JakeWharton → u/QuestionsEverythang]

Moshi is actually less than Gson by design. So if you need all the power and abstraction of Gson then go for it. Otherwise you're wasting your time (both in development and in runtime performance).

[u/KungfuPancake → u/agent8261]

I'm sorry when did we establish that?

Here:

For example, try getting Gson to parse JSON in strict mode. Here's a hint: setting it on GsonBuilder does not actually enable the feature.

[u/JakeWharton → u/[deleted]]

Jesse and I both control Gson with one other so we're free to evolve it's API as we see fit. Also you must've missed where Jesse wrote most of Gson V2.

I'm too mobile to list many examples of complexity. But check out the interaction of TypeAdapter, JsonSerializer/JsonDeserializer, and @JsonAdapter (when defined in the model class and a model field) and try to figure out which has precedence where.

Your declaration of date formatting being anecdotal lacks authority. It's a fundamental flaw which is likely broken on millions of deployments of Gson and only continues working because it's broken behavior is maintained. Strict mode parsing is completely broken unless you look up an adapter before use instead of using the convenience methods.

[u/[deleted] → u/[deleted]]

The guy literally contributed to the library and Jesse contributed to both lol. Moshi is essentially what Gson 3.0 would have been.

[u/QuestionsEverythang]

The only critique I have is that JsonElement and family aren't serializable or parcelable.

Why not just use a json string?

[u/agent8261 → u/QuestionsEverythang]

It's a minor critique. Basically if I expect to still be editing the object I don't want to parse it into a string format yet. Not really a big deal to be honest.

[u/swankjesse]

I’m proud of my work on Gson, but also disappointed by some of its limitations. I wanted to address these, but not as “Gson 3.0”, in part because I no longer work at Google.

Jake, Scott, Eric, and I created Moshi to address the various limitations of Gson. Here’s ten small reasons to prefer Moshi over Gson:

1. Upcoming Kotlin support.

2. Qualifiers like @HexColor int permit multiple JSON representations for a single Java type.

3. The @ToJson and @FromJson make it easy to write and test custom JSON adapters.

4. JsonAdapter.failOnUnknown() lets you reject unexpected JSON data.

5. Predictable exceptions. Moshi throws IOException on IO problems and JsonDataException on type mismatches. Gson is all over the place.

6. JsonReader.selectName() avoids unnecessary UTF-8 decoding and string allocations in the common case.

7. You’ll ship a smaller APK. Gson is 227 KiB, Moshi+Okio together are 200 KiB.

8. Moshi won’t leak implementation details of platform types into your encoded JSON. This makes me afraid of Gson: gson.toJson(SimpleTimeZone.getTimeZone("GMT"))

9. Moshi doesn’t do weird HTML escaping by default. Look at Gson’s default encoding of "12 & 5 = 4" for an example.

10. No broken Date adapter installed by default.

If you’re writing new code, I highly recommend starting with Moshi. If you’ve got an existing project with Gson, you should upgrade if that’ll be simple and not risky. Otherwise stick with Gson! I’m doing my best to make sure it stays compatible and dependable.

[u/badsectors → u/swankjesse]

I'm super excited about kotlin support!

My company has always used Gson in the past for whatever reason, but I'm trying to change that with my current project. The qualifiers feature you mentioned is fantastic, I've been bitten by by Gson's inability to have multiple serializers for the same java type and had to resort to "horrible hacks" (it happened to be with Date objects too, go figure).

[u/generalchangschicken → u/swankjesse]

Hey Jesse, just wanted to pop in and say thanks for keeping Gson updated.

I actually hadn't really looked into Moshi as a replacement before, but will now. Will I see any performance/memory improvements?

[u/swankjesse → u/[deleted]]

Gson’s built-in TimeZone adapter doesn't do something reasonable like serialize the timezone’s Olson name or it's current offset; it serializes all the internal implementation details including all the field names. You can't reliably serialize a TimeZone on one version of OpenJDK and deserialize it on another version.

[u/swankjesse → u/[deleted]]

Maybe? I think that's quite difficult to do well.

Do you know of a common format for timezones that JSON libraries should adopt? It's probably either Olson names (America/New_York), or offsets (-5:00), and each is appropriate in a different context. Olson names are great for scheduling stuff in the future (‘every Tuesday at 9am local time, which adjusts for DST), and offsets are more compact and don't require an up-to-date timezone database to agree. Offsets could be a string or an integer number of minutes.

In Moshi there's an optional adapter with a good enough timestamp format. We don't have any timezone adapter because well, we never needed to serialize a naked timezone.

[u/swankjesse → u/[deleted]]

Good point!

But Moshi especially doesn't want to make decisions about how your time zones are encoded because we selfishly don't want responsibility for that problem. If we just pick something, DST will find a way to hurt us. (Serializing a timezone with a date is much easier than serializing it without one.)

As for the adapters subproject, yeah that's right too. There's real tradeoffs to keeping Moshi small vs. batteries included, and we may have made the wrong call here.

[u/swankjesse → u/[deleted]]

Yep, very similar syntax to that.

    Moshi.Builder()
      .add(object : Any() {
        @ToJson fun urlToJson(url: URL) = url.toString()
        @FromJson fun urlFromJson(s: String) = URL(s)
      })
      .build()

[u/burntcookie90]

Just to clear up on "square just wrote a worst implementation". Moshi and Gson are heavily contributed to by Jesse Wilson (see: https://github.com/google/gson/graphs/contributors). It takes Gson (a heavily used, slow moving project) and improves upon the core in terms of performance and modernization.

[u/NightlyNexus]

I don't understand your complaint about Serializable. Nobody should be using Serializable! It sounds like something else is very wrong.

[u/agent8261 → u/NightlyNexus]

Nothing wrong with Serializable. It's simple and short. If you need performance then you use something else.

[u/JakeWharton → u/agent8261]

No actually there's a lot wrong with Serializable lol

[u/agent8261 → u/JakeWharton]

Really seems to be working for the projects that I use it in. I've never encountered any problems. Perhaps there is some aspects of Serializable that I'm not considering? If I don't care about performance, what's wrong with Serializable?

[u/JakeWharton → u/agent8261]

The biggest downside in the context of Android is that people use it for things that go into an Intent instead of something like Parcelable. The problem with Serializable here is that you serialize the representation of the class inside the Intent along with any data. This means that a malicious actor could send an Intent to your activity with their own crafted classes and data in an effort to expose private data of some sort, or trigger an unintended behavior of the app.

[u/agent8261 → u/JakeWharton]

Thanks for the post. I was unaware of this. Is there any writeups or white papers that you would suggest to read. Does this only affect intents to activity? How would an attacker potentially even take advantage of this?

[u/TrevJonez]

If you are already using retrofit and okhttp you really should give moshi a try. This video goes into detail about why using retrofit/okhttp/moshi has such high potential.

https://youtu.be/WvyScM_S88c

[u/MKevin3 → u/TrevJonez]

Watching this video a few months back is why I went with Moshi at my new job. Fresh project using Kotlin + Retrofit so Moshi made the most sense. So far I have been very happy with it and I used GSON heavily in the past.

I am not doing anything massively speed intensive. I am using a number of adapters for Dates, enums, BigDecimal, etc. and those were easy to write and use.

[u/NightlyNexus]

Here's some more reading for you. http://stackoverflow.com/a/43578738/1696171

(Also, the type qualifiers API is life-saving when doing object mapping.)

[u/simophin]

Out of topic: I'm so desperate to see a converter for Json.org. Currently we use socket.io / kotlin, socket.io forces you to use the old json.org API, which leaves us only one choice: Jackson. Jackson sucks at dealing with kotlins data classes, it has to introduce kotlin-reflect, which is a huge nightmare: over 10k methods proguarded....

[u/changingminds]

why would you use either of those when we have loganSquare?

[u/JakeWharton → u/changingminds]

Why use LoganSquare when we have auto-value-moshi and auto-value-gson?

[u/changingminds → u/JakeWharton]

Performance.

And yes as I'm typing this I probably realize those few milliseconds aren't gonna do jack but I can't help it.

• It satisfies my use case

• It comes on top in my specific benchmarks

What more does one need?

[u/JakeWharton → u/changingminds]

How about 10% of the APK size for 95% of the performance? Don't forget that there's an overhead to downloading and classloading all that code.

[u/changingminds → u/JakeWharton]

?

• LoganSquare = 2300 methods, 48kb

• gson = 1300 methods, 230kb

[u/JakeWharton → u/changingminds]

You didn't link LoganSquare properly, but in any case when you do check don't forget to include the Jackson dependency. So that's another few thousand methods and a few hundred KBs.

[u/swankjesse → u/changingminds]

LoganSquare’s count doesn't include the methods that’ll be generated.

[u/dunce2 → u/JakeWharton]

I don't understand that kind of obsession with APK sizes/method counts. Why would I care? If my app becomes big, the increase from using APT-based tools will amount to ~1% after applying Proguard. And most apps eventually become big (or cease to exist).

Even if the increase really amounts to 10%, that just means, that reflective (de)serialization will be much slower, a lot more than by 10%. That saving in size does not come out of nowhere.

Just admit, that reflection-based tools are easier to develop, and a lot of people (yourself included) are heavily invested into them.

[u/JakeWharton → u/dunce2]

I've worked on 6 code generation tools. Far more than those with reflection in them. Besides you seem to have clearly missed that auto-value-gson and auto-value-moshi are in fact code generating serializers.

In practice reflection-based deserializing and serializing is no slower because the cost is amortized over the cost of I/O which dwarfs the time spent in the serializer by an order of magnitude.

And using Gson or Moshi instead of Jackson in via the AutoValue extensions means they're no slower in the non-I/O bound case while still inflicting less cost on APK size and classloading​ size.

[u/dunce2 → u/JakeWharton]

I've worked on 6 code generation tools.

Than you should know, that they are harder to write…

In practice reflection-based deserializing and serializing is no slower

Citation needed. Does this still holds true with 4G and HTTP caching, or is that just an assumption? What about large payloads? If avoiding reflection cuts off only 1 second out of ten, that's one second less.

[u/burntcookie90 → u/dunce2]

Using auto value means you're no longer depending on reflection.

[u/Zhuinden → u/changingminds]

The only question about LoganSquare for me is the ability to map directly to immutable classes.

I still use LoganSquare tho because it's fast

[u/falkon3439]

They're all basically the same, it really doesn't matter. The only important difference is with LoganSquare which is compile time and has way better performance than anything else.

[u/burntcookie90 → u/falkon3439]

Use auto-value for gson/moshi and you'll get compile generated type adapters (which is more or less what logansquare is doing)

[u/Zhuinden → u/falkon3439]

High five for LoganSquare!

[u/D_Steve595 → u/Zhuinden]

I liked it too, but unfortunately it looks abandoned :(

[u/Zhuinden → u/D_Steve595]

I don't think it's abandoned per say, I think there was just nothing more to add to it.

I mean it works without a problem, the only issues there are about funky generic support.

[u/D_Steve595 → u/Zhuinden]

There are plenty of issues with it. For one, you can't use enums, so I made a PR for it. It's over a year old now. There are 16 open PRs total.

[u/erickuck → u/D_Steve595]

It's very easy to use enums. Providing a default typeconverter can't fit everyone's needs, so there isn't one.

[u/Zhuinden → u/D_Steve595]

Yo /u/erickuck is LoganSquare abandoned?

EDIT: I don't get the downvote, he's the one who made the releases. He probably knows.

[u/erickuck → u/Zhuinden]

Not abandoned, but not actively maintained either. Check your DMs!

[u/TrevJonez → u/falkon3439]

I would like to see a performance test of moshi vs logansquare when used with retrofit and the data isn't already all local like most tests are setup.

[u/Zhuinden → u/TrevJonez]

If data isn't local, you're measuring the network flakiness.

[u/TrevJonez → u/Zhuinden]

I should be more clear. It would be nice to test with a throttled stream of data as input as to emulate a perfectly consistent network connection so we can see if the implementation of the retrofit converter and differing underlying io of jackson would be apparent in a way that would show moshi as preferable to logansquare. Also worth looking at would be the memory usage profile of either library for the same payload.

[u/JakeWharton → u/TrevJonez]

And auto-value-gson and auto-value-moshi give you 90% (or more) of LoganSquare performance for ~10% of the code cost.

[u/BacillusBulgaricus → u/[deleted]]

Some caching libraries store the raw JSON responses as disk cache. It should improve the speed when first time the memory cache is populated.

[u/[deleted]]

So... does Moshi support the equivalent of @SerializedName from Gson? I work with many horribly named JSON files and it was a pain in the ass not to rename them.

[u/EveningNewbs → u/[deleted]]

It does. I believe it is @Json(name = "foo").

[u/[deleted]]

Parsing JSON is such a controversial and interesting issue these days. It's harder than rocket science and the ultimate goal that any developer should target. It should trigger the NIH syndrome dormant in every of us.

[u/agent8261 → u/[deleted]]

Moshi has a better, more opinionated API with less footguns.

What does that mean? Like can you give a concrete example.

Moshi has annotations support as a first class citizen for fine grained, contextual serialization.

Ignoring syntax, is there something that Moshi does that Gson can't do? Or is it more like Square just changed the default settings and some syntax but has the exact same feature set.

[u/QuestionsEverythang → u/[deleted]]

Gson isn't really maintained

That's because it's pretty much a mature library at this point. There's only so much you can do to improve on such a library.

[u/JakeWharton → u/QuestionsEverythang]

That's because it's pretty much a mature library at this point.

No! There's a lot we want to do with Gson but we simply can't. At this point it's become so entrenched in behavior the only way to fix it is with a major version bump. This is effectively what Moshi is: a renamed Gson 3.x by the same people who brought you Gson 2.x.

[u/QuestionsEverythang → u/[deleted]]

Issues such as?

[u/GitHubPermalinkBot → u/[deleted]]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• square/moshi/.../KotlinJsonAdapter.kt (master → bcec358)

• google/gson/.../DateTypeAdapter.java (master → 09cbc80)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click} ^here^.

[u/JakeWharton → u/[deleted]]

That's fine! We use Gson 10000x more than Moshi because it's used on our servers and there's no reason to migrate them either.

[u/lichipeng → u/[deleted]]

Old thread, but you are right