Json4s

One AST to rule them all

JSON4S

At this moment there are at least 6 json libraries for scala, not counting the java json libraries.
All these libraries have a very similar AST. This project aims to provide a single AST to be used by other scala
json libraries.

At this moment the approach taken to working with the AST has been taken from lift-json and the native package
is in fact lift-json but outside of the lift project.

Lift JSON

This project also attempts to set lift-json free from the release schedule imposed by the lift framework.
The Lift framework carries many dependencies and as such it's typically a blocker for many other scala projects when
a new version of scala is released.

So the native package in this library is in fact verbatim lift-json in a different package name, this means that
your import statements will change if you use this library.

importorg.json4s._importorg.json4s.native.JsonMethods._

After that everything works exactly the same as it would with lift-json

Jackson

In addition to the native parser there is also an implementation that uses jackson for parsing to the AST.
The jackson module includes most of the jackson-module-scala functionality and the ability to use it with the
lift-json AST.

To use jackson instead of the native parser:

importorg.json4s._importorg.json4s.jackson.JsonMethods._

Be aware that the default behavior of the jackson integration is to close the stream when it's done.
If you want to change that:

All features are implemented in terms of above AST. Functions are used to transform
the AST itself, or to transform the AST between different formats. Common transformations
are summarized in a following picture.

Summary of the features:

Fast JSON parser

LINQ style queries

Case classes can be used to extract values from parsed JSON

Diff & merge

DSL to produce valid JSON

XPath like expressions and HOFs to manipulate JSON

Pretty and compact printing

XML conversions

Serialization

Low level pull parser API

Installation

You can add the json4s as a dependency in following ways.
Note, replace XXX with correct Json4s version.

SBT users

For the native support add the following dependency to your project description:

Extracting values

Case classes can be used to extract values from parsed JSON. Non-existing values
can be extracted into scala.Option and strings can be automatically converted into
java.util.Dates.
Please see more examples in ExtractionExampleSpec.scala.

By default the constructor parameter names must match json field names. However, sometimes json
field names contain characters which are not allowed characters in Scala identifiers. There's two
solutions for this (see LottoExample.scala for bigger example).

Extraction function tries to find the best matching constructor when case class has auxiliary
constructors. For instance extracting from JSON {"price":350} into the following case class
will use the auxiliary constructor instead of the primary constructor.

List, Seq, Array, Set and Map (note, keys of the Map must be strings: Map[String, _])

scala.Option

java.util.Date

Polymorphic Lists (see below)

Recursive types

Serialization of fields of a class (see below)

Custom serializer functions for types which are not supported (see below)

Serializing polymorphic Lists

Type hints are required when serializing polymorphic (or heterogeneous) Lists. Serialized JSON objects
will get an extra field named 'jsonClass' (the name can be changed by overriding 'typeHintFieldName' from Formats).

ShortTypeHints outputs short classname for all instances of configured objects. FullTypeHints outputs full
classname. Other strategies can be implemented by extending TypeHints trait.

Serializing fields of a class

To enable serialization of fields, a FieldSerializer can be added for some type:

implicit val formats = DefaultFormats + FieldSerializer[WildDog]()

Now the type WildDog (and all subtypes) gets serialized with all its fields (+ constructor parameters).
FieldSerializer takes two optional parameters which can be used to intercept the field serialization:

Serializing classes defined in traits or classes

We've added support for case classes defined in a trait. But they do need custom formats. I'll explain why and then how.

Why?

For classes defined in a trait it's a bit difficult to get to their companion object, which is needed to provide default values. We could punt on those but that brings us to the next problem, the compiler generates an extra field in the constructor of such case classes. The first field in the constructor of those case classes is called $outer and is of type of the defining trait. So somehow we need to get an instance of that object, naively we could scan all classes and collect the ones that are implementing the trait, but when there are more than one: which one to take?

How?

I've chosen to extend the formats to include a list of companion mappings for those case classes. So you can have formats that belong to your modules and keep the mappings in there. That will then make default values work and provide the much needed $outer field.

Serializing non-supported types

It is possible to plug in custom serializer + deserializer functions for any type.
Now, if we have a non case class Interval (thus, not supported by default), we can still serialize it
by providing following serializer.

Now, the above example has two problems. First, the id is converted to String while we might want it as an Int. This
is easy to fix by mapping JString(s) to JInt(s.toInt). The second problem is more subtle. The conversion function
decides to use JSON array because there's more than one user-element in XML. Therefore a structurally equivalent
XML document which happens to have just one user-element will generate a JSON document without JSON array. This
is rarely a desired outcome. These both problems can be fixed by following transformation function.

Low level pull parser API

Pull parser API is provided for cases requiring extreme performance. It improves parsing
performance by two ways. First, no intermediate AST is generated. Second, you can stop
parsing at any time, skipping rest of the stream. Note, this parsing style is recommended
only as an optimization. Above mentioned functional APIs are easier to use.

Consider following example which shows how to parse one field value from a big JSON.

Pull parser is a function Parser => A, in this example it is concretely Parser => BigInt.
Constructed parser recursively reads tokens until it finds FieldStart("postalCode")
token. After that the next token must be IntVal, otherwise parsing fails. It returns parsed
integer and stops parsing immediately.