Move library from Newtonsoft.Json to System.Text.Json

[tipa]

Microsoft & many developers have been moving their apps & libraries from Newtsoft.Json to System.Text.Json recently (e.g. the Microsoft Graph SDK for .NET).
It would be very appreciated if this library could be moved as well. Not only is System.Text.Json faster and more efficient, it is also already used by many developers and libraries. Newtonsoft.Json isn't exactly the smallest .dll and increases the binaries of apps we are creating with the Google API Library for .NET.

This suggestion has been posted by @LindaLawton in #1464 (comment) before and I have read the discussion following on it but I was afraid that this doesn't get the visibility needed when not posted as an own feature request.

[jskeet]

The answer is basically the same though: it would be a breaking change, and one we basically wouldn't take unless we moved to a new major version, which is rather unlikely.

We hope to eventually removed the dependency on Google.Apis.Auth and indirectly Newtonsoft.Json for the Google.Cloud.* libraries, but even that's a long-term goal rather than anything imminent.

[LindaLawton]

@jskeet I understand and respect your dedication for the new Google.Cloud.* library.

However the thing is that the Google.Apis.* library has been around a lot longer. I have personally been using it at least since 2011. This library is not going away just because there is the new shinny Google.Cloud.* library which does not support most of the discovery services apis that this library supports. We have users of this library which deserve your support and dedication as well.

As long as Microsoft continues to release new versions of .Net this library needs to and must grow with that and not become stagnant.

I would like to add if I remember correctly. There was a time when you removed support for .net 3.5 without telling the community at all. That was a huge breaking change for me personally one day it worked the next it didn't. So I don't think you should be that concerned with breaking changes. I just think that they should be voiced to the community first this time.

[jskeet]

I don't think Json.NET is going anywhere though. Making a breaking change and releasing a new major version feels like it would be significantly disruptive. I don't think it's worth that just to remove a dependency, when we don't expect to make other significant changes.

We'll keep supporting this library and releasing new API versions, but that doesn't mean we're going to put in the large amount of effort and cause the large amount of disruption that this would cause, when the existing situation may not be ideal but works fine.

I would like to add if I remember correctly. There was a time when you removed support for .net 3.5 without telling the community at all. That was a huge breaking change for me personally one day it worked the next it didn't. So I don't think you should be that concerned with breaking changes. I just think that they should be voiced to the community first this time.

I don't remember the details of that exactly (and if we really didn't make any announcement, I regret that.). But I suspect that it only happened after .NET 3.5 itself had stopped being supported by Microsoft for a significant length of time. That's very different from making a breaking change to supported platforms. I am concerned with breaking changes, and I don't think you'll convince me that I shouldn't be.

[LindaLawton]

I suspect that it only happened after .NET 3.5 itself had stopped being supported by Microsoft for a significant length of time.

Well then If we follow along that train of thought and we know already that .NET Framework 4.5.2, 4.6, 4.6.1 will reach End of Support on April 26, 2022

Can we expect it to be addressed at the time we remove support for 4.5?

If so do we have a definition for "significant length of time"?

[jskeet]

I think we should address the detailed supported framework timelines in a separate issue, keeping this one to the Newtonsoft.Json dependency. However, I wouldn't expect to create a new major version just to remove support for frameworks that are already end-of-life by Microsoft. So if we decide to stop supporting .NET 4.5, I don't think we'd take a major bump for that. We would definitely try to make sure it's communicated well though. (I think it's more likely that we'll drop support for netstandard1.3 to be honest - but again, we'd communicate that clearly.)

In general (across GAX and Cloud libraries) we take a major version bump as an opportunity to reassess our supported platforms, but I don't think we should penalise developers who are already making sure they stay up-to-date with supported platforms by making breaking changes unless we have a really good reason to, and again I don't think the desire to drop a working dependency is a sufficient reason to create the breaking change.

[LindaLawton]

Not only is System.Text.Json faster and more efficient, it is also already used by many developers and libraries. Newtonsoft.Json isn't exactly the smallest .dll and increases the binaries of apps we are creating with the Google API Library for .NET.

Already working is not a question but is it the best solution? Efficiency and size are very important IMO.

[jskeet]

No solution is going to be perfect for everyone - but given that these libraries are in maintenance mode, I don't regard this as a critical issue.
I guess in a perfect world we'd have multiple major versions so that those who wish to stay on 1.x can do so without taking breaking changes (but still getting new API versions) and a parallel 2.x which has taken all the breaking changes we might want to. But we just don't have the resources to do that, I'm afraid.

[LindaLawton]

As always we appreciate everything you and the team do. Maintaining an OS project is a thankless job. Let me take the time to Thank you.

Please keep us updated on this.

[guillaume86]

Meanwhile, would it be acceptable to just add the [JsonPropertyName] attributes for a NET_50_OR_GREATER target?

I don't think that would be considered a breaking change but would solve my case (serialization to a jsonb column with EF Core, I do not have control on the serializer that is used).

[jskeet]

@guillaume86: Please could you file a new issue with the details of what you're trying to achieve, and why it needs new attributes to be applied? It sounds like it's a somewhat different use case than "Please migrate off Newtonsoft.Json" in this case. (Can your serialization not just use the default property names?) There's some potential there, although we wouldn't target .NET 5 as it's not an LTS - we'd make it .NET 6.0+, if we do it at all. To set expectations, I doubt that we'll be able to put much time into even considering this until Q1 of 2022.