Replace multi_json with json

[sferik]

Since Rails 4 will require Ruby 1.9 and since Ruby 1.9 includes json in the standard library, multi_json is no longer necessary. I am a longtime maintainer of multi_json but will stop supporting the library in June.

This patch replaces multi_json with stdlib json. It will use the json gem if a newer version is available.

I have already submitted similar pull requests to execjs, sprockets, and uglifier, so multi_json need not be a dependency of Rails 4 applications. This should have the effect of making JSON parsing and generation somewhat faster by removing an abstraction layer that is no longer necessary.

[haileys]

👍 for killing multi_json

[vipulnsward]

👍

[steveklabnik]

🤘

[chuyeow]

Is it too late to get this backported to 4-0-stable?

Btw, love your approach, @sferik

[canweriotnow]

[teamon]

What about oj and yajl support?

[nirvdrum]

Not to speak for @teamon, but I think the problem is there are JSON documents that the json library cannot or will not parse. In these cases, using an alternative JSON processor is necessary. While those libraries certainly can be used directly, this change will break existing uses of ActiveSupport's JSON processing that have worked fine since the 2.x days. If swapping out JSON processors isn't going to be possible, there should probably be a caveat in the upgrade guide that this could break existing apps.

[haileys]

@nirvdrum If there are JSON documents that are legal according to the JSON spec that json cannot parse, you should file a bug with json. If they are not legal according to the spec, then they are not JSON documents.

[nirvdrum]

@charliesome Some it cannot parse because its architecture fundamentally doesn't support. E.g., docs of certain sizes will blow out memory in json but work with a very reasonable footprint in yajl. And json has deliberately hard-coded a depth limit in nested structures. I'd imagine that was done as a stop-gap to blowing out memory, but it's not an accidental bug. The error message very clearly tells you it will not parse that document (see: https://github.com/flori/json/blob/master/lib/json/common.rb#L119).

That aside, even if it could subsume all other JSON processors in some future release, then you'd have to require a version not bundled with stdlib anyway, kinda negating the purported benefit of this being bundled in stdlib.

[haileys]

@nirvdrum That's a fair point, I hadn't considered that. It seems to me that large documents requiring a 'SAJ' (is that a thing?) parser are probably out of scope of what Rails should handle for you, given that it's likely you'll need to work with them specially anyway.

[nirvdrum]

I think if you know from the outset that's a limitation, it's a fair point. The way I've seen it happen is a bunch of code is already using ActiveSupport's JSON interface, a problematic doc comes along, and then the engine is swapped out. Regardless of the rationale, the point I was raising is that json is not a drop-in replacement for other providers but the ActiveSupport interface is going to look the same and as a result code that previously worked no longer will. My preference is to retain the ability to swap out the engine, whether that be with multi_json or by other means. But, barring that, I think it's misleading to indicate that a multi_json-like lib is no longer necessary and thus safe to remove. Something in the client app will have to be rewritten and mentioning that in either the CHANGELOG or upgrade guide probably makes sense (admittedly, I don't which one makes the most sense).

[mhenrixon]

But I want to use OJ for performance reasons how do I go about that now?

[jlecour]

I'd also like to use a different JSON library than Ruby's default, within Rails.

For the moment, I'm working on an API, built with Rails 4 and ActiveModel::Serializers and I'd really want to use Oj or Yajl.