BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Interview: James Newton-King on Json.NET 4.5

Interview: James Newton-King on Json.NET 4.5

This item in japanese

Bookmarks

The Json.NET project just released version 4.5 of their JSON framework for .NET which includes many new features and a dramatic speed enhancement. InfoQ recently spoke with Json.NET creator James Newton-King about the new release and the project as a whole.

InfoQ: What are some of the features you are most pleased with among these last 2 major releases (Json.NET 4.0 & 4.5)?

James Newton-King: [For Json.NET 4.0] I'm happy with the dynamic support that .NET 4.0 allowed me to provide. The features I enjoy adding the most are ones where I'm learning at the same time I'm implementing them.  For example, implementing IDynamicMetaObjectProvider on JObject/JArray/JValue  [was definitely a learning experience as I wanted the current version to benefit] while at the same time keeping it separate so that the dynamic features could be excluded from the older .NET builds that Json.NET supports.

Making the ISO 8601 date format the default date serialization format in Json.NET is my favourite Json.NET 4.5 feature. Dates in JSON have been something of a nemesis for me and although Json.NET has used Microsoft's date format since the beginning I've never liked it. Interoperability with JSON libraries on non-Microsoft platforms was obviously a problem but the bigger one to me was that dates weren't easily readable. For a developer debugging their code the ISO format - "2009-02-15T00:00:00Z" - is much more readable than Microsoft's old format: "\/Date(1198908717056)\/". Surprisingly for a breaking change I've yet to have a single person complain or bring it up so .NET developers must like it.

InfoQ: What are some of the key features you would like to see added in a future release? (Your feature listing on Codeplex mentions JSON Recursion Limit Support, is this all?)

J.N.K. - There are two reasons for adding JSON recursion limit support. The first is because the Microsoft JSON serializers support it and I like to support everything they do that I think is useful, and adding a limit is useful if you're exposing an endpoint to the public and want to lock it down. The other is the ASP.NET MVC team will use it with the Web API. Right now they have implemented it themselves but it is a very simple feature to add and I want the way the Web API works with JSON and the way Json.NET works with JSON to be as similar as possible.

When it comes to adding new features to Json.NET I never plan things out. What I tend to do is look at what questions Json.NET developers are asking on sites like StackOverflow and what bugs they're raising to me, and then I come up with ideas that makes things easier for them. Sometimes that is a new feature while others it is improving a gap in the documentation to let developers know it is already possible. 

InfoQ: You mentioned that "A sweet bug fix means that a performance test now runs 70,000% faster" Can you elaborate on this?

J.N.K. - A Microsoft developer stress testing Json.NET noticed that deserializing 100,000 nested arrays to LINQ to JSON objects took significantly longer than it should. The reason for the bad performance was that LINQ to JSON objects check for a recursive loop, i.e. an array isn't its own parent, and each time a new nested array was deserialized it would have to check all its parents, e.g. array 90,001 will check its 90,000 parents, array 90,002 will check its 90,001 parents, etc. Obviously not ideal.

The solution was quite simple: check whether the item that is being added has any children. If an array has no children then it can't be its own parent so the recursive parent check can be skipped. The one line change resulted in an instant improvement from 43 seconds to 63 milliseconds.

InfoQ: Release 4.0-6 highlighted performance gains in comparison to the .NET framework options. How important do you consider Json.NET performance vs its overall feature-set?

Every developer benefits from features that improve developer productivity but only some need extreme performance so it is important to balance the two. I make sure that Json.NET is faster than the .NET framework serializers as well as offering more features.

InfoQ: Thanks again to James Newton-King for his time. Complete information on all of the new features can be found at this announcement, and the overview of all the project's features are available at it's Codeplex site.

Rate this Article

Adoption
Style

BT