With Jackson 2.12, Jackson XML format module (jackson-dataformat-xml) functionality improved a lot (see this earlier blog post). Specifically it became possible to actually use Jackson’s Tree Model (JsonNode) for reading and writing XML.

Reading XML into JsonNode with Jackson 2.12

By default you can read XML content like:

<root>
  <value>Hello</value>
</root>

with XmlMapper (using xmlMapper.readTree(xmlSource)) and get same Tree value as if reading this JSON with regular JsonMapper:

{"value":"Hello"}

But if you serialize resulting JsonNode (xmlMapper.writeValueAsString(treeValue)) output will look something like:

<ObjectNode><value>Hello</value></ObjectNode>

which is consistent structurally (there is the fundamental structural mismatch between XML and JSON, “structural impedance”) but not quite what you would typically want.

Disparity between XML and JSON data models

The…

What is “Smile format”?

First things first: since some of you may not be familiar with the data format called Smile, here’s a brief introduction:

1. It is a “binary JSON” format: it has the same logical model as JSON (has same value types) but uses binary encoding for compactness (smaller data size), allowing faster reading and writing
2. Specification can be found in smile-format-specification Github repo
3. Smile encoding is supported my many libraries and frameworks (see above-mentioned Github repo for links): Java support is via Jackson jackson-dataformat-smile module
4. It is similar in many ways to other “binary JSON” formats like newer CBOR or (slightly) older…

Background: what NEW have I OSS’d lately?

It has been a while since I wrote a new tool or library of any kind (excluding Jackson modules)
In fact, my last new Open Source library must be be “Gorp” from 2018 — a nifty (*) multi-regexp library, inspired by Elastic’s “grok” — but one that I haven’t developed much further (**).

So I have thought about maybe writing something small, something different, to avoid getting too stuck with things I have “already done”.

(*) … or so I thought. …

When serializing content as JSON (or another format Jackson supports), Jackson by default just writes out all property values as they are.
Many users want to change this behavior so that certain property values should be “filtered out”, not written as output. For example so that only properties with non-null values should not be written — this can help reduce message and sparse data record sizes.

Jackson offers multiple ways to limit writing of output by various “filtering” mechanisms: for an overview read “Every day Jackson usage, part 3: Filtering properties” (written 10 years ago butcovers most choices). …

(how to serialize contents of List<String> in alphabetic order, using “helper” List subtype, custom JsonSerializer)

On Customizing Jackson value Serialization

Jackson-databind allows a wide range of customization options for formatting output of many types, both using configuration settings and annotations. But there are sometimes cases where more customization is necessary.

In case of non-structured (scalar) types and user-defined POJOs, it is quite easy to alternative just implement custom JsonSerializer if bigger changes to output are required. Such serializers may then be easily added using SimpleModule like so:

ObjectMapper mapper = JsonMapper.builder()
   .addModule(new SimpleModule()
       .addSerializer(new MyValueSerializer()
   ).build();

or using @JsonSerialize(using = MyValueSerializer.class) either on property, or…

First there was just JSON

Although Jackson started simply as a JSON parser library (see “Brief history of Jackson”), over the years it has grown to support dozen other data formats using extensions called (dataformat) Modules. At high level the API used is identical to that of reading and writing JSON — jackson-databind package and its API is format-agnostic — although there are typically some configuration settings that vary. So in theory it should be very easy to start using Jackson with one of supported (*) formats.

In practice, however, some formats are handled very similar to JSON (for example “native JSON” formats like CBOR…

Jackson support of Guava datatypes: basics

Jackson core components like databind do not use Guava for anything: not because it was not a very useful library (it is!), but to keep Jackson core components dependency-free (*).
But there is an extension module available to let Jackson users use databind to read and write many Guava values: jackson-datatype-guava extension modules.
It is registered like so:

ObjectMapper mapper = JsonMapper.builder()
   .addModule(new GuavaModule())
   .build(); // Jackson 2.10+
// or with earlier Jackson versions:
ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new GuavaModule());

and after doing this you can read and write many of standard Guava datatypes.

For example:

ImmutableList<Integer> list =…

First, a disclaimer: I do not know if this is a good idea or not — and I definitely do not promote its application, if any, at this point. :)

Background: JSON from not JSON

A user presented me with a use case for Jackson JSON parsing, wherein query parameters can contain String and Number values, like so:

http://foo.bar.com?id=125&name=Bob

and wanted to just parse them into JsonNode:

JsonNode nameNode = mapper.readTree(request.getParam("name"));

This does not — and should not — work as String Bob is not valid JSON (all JSON String values MUST be quoted).

But in YAML Norway is False!

But it got me thinking of YAML which is blessed AND…