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 the 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 {latestVersion} with correct Json4s version.

Extras

Migration from older versions

3.3.0 ->

json4s 3.3 basically should be source code compatible with 3.2.x. Since json4s 3.3.0, We've started using MiMa for binary compatibility verification not to repeat the bin compatibility issue described here.

The behavior of .toOption on JValue has changed. Now both JNothing and JNull return None. For the old behavior you can use toSome which will only turn a JNothing into a None.

3.0.0 ->

JField is no longer a JValue. This means more type safety since it is no longer possible to create invalid JSON where JFields are added directly into JArrays for instance. The most noticeable consequence of this change are that map, transform, find and filter come in two versions:

Use *Field functions to traverse fields in the JSON, and use the functions without 'Field' in the name to traverse values in the JSON.

2.2 ->

Path expressions were changed after version 2.2. Previous versions returned JField, which unnecessarily complicated the use of the expressions. If you have used path expressions with pattern matching like:

valJField("bar", JInt(x)) = json \ "foo" \ "bar"

it is now required to change that to:

valJInt(x) = json \ "foo" \ "bar"

Parsing JSON

Any valid json can be parsed into internal AST format. For native support:

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 are two solutions for this. (See LottoExample.scala for a bigger example.)

If the json field names are snake case (i.e., separated_by_underscores), but the case class uses camel case (i.e., firstLetterLowercaseAndNextWordsCapitalized), you can convert the keys during the extraction using camelizeKeys:

See the "Serialization" section below for details on converting a class with camel-case fields into json with snake case keys.

The extraction function tries to find the best-matching constructor when the 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 that are not supported (see below)

If the class contains camel-case fields (i.e: firstLetterLowercaseAndNextWordsCapitalized) but you want to produce a json string with snake casing (i.e., separated_by_underscores), you can use the snakizeKeys method:

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 the short classname for all instances of configured objects. FullTypeHints outputs the full classname. Other strategies can be implemented by extending the TypeHints trait.

Serializing fields of a class

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

implicitvalformats=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, that 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 a 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 a JSON array. This is rarely a desired outcome. These both problems can be fixed by the following transformation function.

Low-level pull parser API

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

Consider the following example, which shows how to parse one field value from a big JSON:

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

Kudos

The original idea for the DSL syntax was taken from the Lift mailing list (by Marius).