aka “Why is UUID.fromString() so slow?”

Similar to my recent adventure into evaluating performance of String.format() for simple String concatenation, I found another potentially meaningful case of widely used (and useful) JDK-provided functionality that seems to significantly under-perform: decoding of java.util.UUID from a String:

UUID uuid = UUID.fromString(request.getParameter("uuid"));

This was found to be a hot spot on profiling done for a web service. Given that decoding should not really be that complicated compared to, say, generating UUIDs, this seemed odd.
(note: I am not the first developer to have noticed this, see f.ex this blog post from 2015)

Given that I once wrote (and still maintain)…

While the final Jackson 2.13.0 is not yet out — there are, however, two release candidates, 2.13.0-rc1 and 2.13.0-rc2 — it’s a good time to check out what will be included.

First things first: whereas Jackson 2.12 release was stock full of new features, 2.13 was planned to be a more modest update: focusing on just one or two bigger things. This is what is happening. The other part of the plan — get it out much quicker — did not quite pan out, partly due to need to patch some of the gaps in new functionality that 2.12 provided…

aka “Why is String.format() SO slow?”

In the past I have found that the functionality in the JDK is usually well optimized, and performs reasonably well for the task, considering general nature and applicability of the functionality offered. So as general guideline I tend to trust that if the JDK has a method for doing something in a simple way it is perfectly fine for most use and likely performs well enough.

But I have also found that occasionally some specific classes or methods may perform surprisingly poorly. …

(Java micro-benchmarking with jmh)

Recently I came across a bit of code solving a relatively common problem — that of finding if a given String contains one of specified characters.
This may be for input validation (refuse Strings that contains certain character(s)), or as a precondition to String modification (escaping / quoting), for example.

It might be used like:

String xmlToCheck = ...;
if (textToCheck.containsAnyOf("&<>'\"")) { // if JDK String had it
// do some escape/quote magic

The implementation I saw (which I’ll show in a bit) looked like it might benefit from optimization, or perhaps could be replaced by a 3rd party…

(how to avoid unnecessary <ObjectNode> wrapper)

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.

By default you can read XML content like:


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


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


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


(that is, “Hadoop Splittable”)

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…

(the Transformative Tool)

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. …

(including use of fully custom exclusion filter)

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)

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()

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

“How to use jackson-dataformat-csv”

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…


Open Source developer, most known for Jackson data processor (nee “JSON library”), author of many, many other OSS libraries for Java, from ClassMate to Woodstox

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store