Jackson is a popular library for handling JSON in Java applications, quickly becoming the de-facto standard in the ecosystem. Starting with version 2, it has also introduced a mature XML implementation alongside its established JSON support.
Adding the Jackson XML module to the project only needs a single dependency – the Jackson XML module itself:
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>2.9.0</version>
</dependency>
And in Gradle:
compile "com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.9.0"
This will automatically pull in all of the other Jackson dependencies that are needed:
Note that the Woodstox StAX library can be excluded and replaced with any other valid implementation of the StAX API.
Jackson is typically used by means of an ObjectMapper instance. In order to work with XML, we’ll instead use the XmlMapper class. This is a direct extension of ObjectMapper and can be used as a replacement, with the exact same API we’re already used to.
The absolute simplest way of working with this is to just use the default configuration:
ObjectMapper objectMapper = new XmlMapper();
However, if we need additional configuration, we can instead construct the Jackson Module manually and set it up as necessary:
JacksonXmlModule xmlModule = new JacksonXmlModule(); xmlModule.setDefaultUseWrapper(false); ObjectMapper objectMapper = new XmlMapper(module);
As of version 2.9.0, the only configuration options for the XML Module are:
Due to the fact that the XmlMapper extends the standard ObjectMapper, we can essentially use all of the standard Jackson ObjectMapper configuration settings and APISs.
For example, we can configure it to produce indented output as follows:
objectMapper.enable(SerializationFeature.INDENT_OUTPUT);
Note that some of these settings might not work with some XML implementations. For example, older versions of Jackson XML depended on Stax2Writer, which didn’t support writing raw characters to the stream. This means that it doesn’t support writing the raw newlines and indentations needed for the INDENT_OUTPUT feature to work.
Jackson is best known for its ability to serialize POJOs into JSON and back, by means of standard conventions and – where necessary – special annotations to give clues to the Jackson library.
As already mentioned, the XmlMapper object directly replaced ObjectMapper, only it works in terms of XML instead of JSON. This means that the API is exactly the same, and it can be used as a direct replacement.
Writing XML is done using the various writeValue methods that Jackson exposes. For example, marshalling some object to XML is done simply by using the writeValueAsString API:
String xml = objectMapper.writeValueAsString(input);
The standard versions of this all exist and work as expected:
As we just explored, we the library handles writing to XML quite well.
We can also read XML, using the various readValue APIs that are part of provided by the ObjectMapper.
For example, reading some XML from an InputStream into a Java Bean:
MyBean bean = objectMapper.readValue(inputStream, MyBean.class);
Again, the standard versions of this all exist, and work as expected:
The Jackson XML module supports the full range of annotations that Jackson provides for annotating our POJOs.
This means that we can have one single set of beans, with one set of annotations and, depending on the ObjectMapper instance, we select whether we get XML or JSON. That’s a huge benefit when it comes to structuring our code, as we no longer have to worry about translating between different beans that represent essentially the same data just to get different serialization formats.
For example, given the following bean:
@JsonPropertyOrder({"age", "id", "name"})
public class Person {
@JsonProperty("_id")
private String id;
private String name;
private int age;
@JsonIgnore
private String note;
}
will produce this JSON:
{
"age":4,
"_id":"12345",
"name":"George"
}
And this XML:
<Person>
<age>4</age>
<_id>12345</_id>
<name>George</name>
</Person>
The Jackson XML module adds some additional support for XML specific features. These annotations allow us to control the XML namespace and local name for elements, including the root element, whether a field is rendered in an element or as plain text, whether the content of an element is rendered in a CData wrapper, and whether a collection should use a wrapper element or not.
@JacksonXmlProperty can be applied to any field in a bean to control the details of the element that is being rendered. This annotation allows us to determine the namespace, the local name, and whether the field is serialized as an Element or an Attribute. For example, the following bean:
For example, the following bean:
public class Person {
@JacksonXmlProperty(
isAttribute = true, namespace = "urn:stackify:jacksonxml", localName = "_id")
private String id;
@JacksonXmlProperty(namespace = "urn:stackify:jackson")
private String name;
private String note;
}
This generates the following XML output:
<Person xmlns:wstxns1="urn:stackify:jacksonxml"
wstxns1:_id="12345">
<wstxns2:name xmlns:wstxns2="urn:stackify:jackson">Graham</wstxns2:name>
<note>Hello</note>
</Person>
The @JacksonXmlRootElement has a similar role to the @JacksonXmlProperty but for the root element of the entire document. This can only adjust the Namespace and Local name – since the root element can never be serialized as an attribute.
For example, let’s look at this Java POJO:
@JacksonXmlRootElement(namespace = "urn:stackify:jacksonxml", localName = "PersonData")
public class Person {
private String id;
private String name;
private String note;
}
When serialized, this will result in the following XML:
<PersonData xmlns="urn:stackify:jacksonxml">
<id xmlns="">12345</id>
<name xmlns="">Graham</name>
<note xmlns="">Hello</note>
</PersonData>
Next, let’s have a look at the @JacksonXmlText annotation.
Simply put, this indicates that an element should be rendered as plain text without another element containing it.
For example, the following POJO:
public class Person {
private String id;
private String name;
@JacksonXmlText
private String note;
}
Will produce this simple XML output:
<Person>
<id>12345</id>
<name>Graham</name>
Hello
</Person>
Naturally, you do have to be careful using this annotation and make sure you’re still generating valid XML.
The @JacksonXmlCData annotation indicates that a CData wrapper should be placed around the content of the element. This can be used in conjunction with the @JacksonXmlText if desired to produce a CData wrapper without an element tag.
Let’s have a look at a POJO using this annotation:
public class Person {
private String id;
@JacksonXmlCData
private String name;
@JacksonXmlText
@JacksonXmlCData
private String note;
}
This will result in the following XML:
<Person>
<id>12345</id>
<name><![CDATA[Graham]]></name>
<![CDATA[Hello]]>
</Person>
The @JacksonXmlElementWrapper annotation is used to override the default setting from setDefaultUseWrapper – as seen above. This can ensure that a collection either does or does not use a wrapper element, and can control what the wrapper element uses for namespace and local name.
When using wrapper elements, we get an additional element added which contains all of the elements from the collection, and when wrapper elements are not used then the individual collection elements are written directly inline:
class Wrapper {
@JacksonXmlElementWrapper(localName = "list")
private List names;
}
This will produce the following XML:
<Wrapper>
<list>
<names>John</names>
<names>Paul</names>
<names>George</names>
<names>Ringo</names>
</list>
</Wrapper>
Whereas, if the JacksonXmlElementWrapper is replaced with:
@JacksonXmlElementWrapper(useWrapping = false)
Then the XML produced won’t contain the list element:
<Wrapper>
<names>John</names>
<names>Paul</names>
<names>George</names>
<names>Ringo</names>
</Wrapper>
The Jackson XML module also has the ability to support the standard JAXB annotations on our beans – instead of needing the Jackson specific ones. This can be useful if we want to use Jackson for the actual XML Serialization but don’t want to depend on it at compile time.
This can also be used to allow JAXB to generate our bean definitions from an XML Schema and have Jackson process them.
This functionality is an additional module that needs to be added in for it to work. It doesn’t work out of the box like the Jackson annotations do. In order to configure this – we need to add the JaxbAnnotationModule to our ObjectMapper as follows:
objectMapper.registerModule(new JaxbAnnotationModule());
We can now write or generate a Java bean with JAXB annotations and simply process it with this XmlMapper.
For example, the following POJO:
@XmlRootElement(name = "employee")
@XmlAccessorType(XmlAccessType.FIELD)
public class EmployeeBean {
@XmlAttribute(name = "_id")
@XmlID
private String id;
@XmlElement
private String name;
@XmlElement
private String type;
}
Will produce the following XML when marshalled:
<employee _id="12345">
<name>Graham</name>
<type>Developer</type>
</employee>
Jackson also has the powerful ability to actually jump into the middle of an existing XML file and either marshall or unmarshall XML to and from that file.
The functionality makes good use of the standard XMLStreamWriter class, and naturally of XMLStreamReader as well. This cool functionality gives us a lot of flexibility to work with existing XML documents and integrate with these cleanly and easily.
The XmlMapper is able to serialize an entire Java bean into a document that is currently being produced, allowing Jackson to integrate and construct the document along with other external actors. This also gives some ability to support constructs that Jackson cannot handle natively – for example, the XML Prolog.
In order to do this, the XmlMapper needs to be called to write values to the XMLStreamWriter object – the same as if we were writing to any other Writer:
StringWriter stringWriter = new StringWriter();
XMLOutputFactory xmlOutputFactory = XMLOutputFactory.newFactory();
XMLStreamWriter sw = xmlOutputFactory.createXMLStreamWriter(stringWriter);
XmlMapper mapper = new XmlMapper();
sw.writeStartDocument();
sw.writeStartElement("root");
mapper.writeValue(sw, employeeBean);
sw.writeComment("Some insightful commentary here");
sw.writeEndElement();
sw.writeEndDocument();
This will produce the following XML:
<?xml version='1.0' encoding='UTF-8'?>
<root>
<employee _id="12345">
<name>Graham</name>
<type>Developer</type>
</employee>
<!--Some insightful commentary here-->
</root>
Here, the XML Prolog, root element, and the comment – are not produced by Jackson XML, but everything inside the EmployeeBean element is.
The opposite of this is also possible – deserializing a Java bean from the middle of an XMLStreamReader.
This can be especially useful if we only care to have Java bean representations for data in the middle of a larger object – for example, if we are parsing an Atom wrapper around the data we are interested in.
In order to do this, the XmlMapper needs to be called to read values from the XMLStreamReader object – the same as if we were reading from any other Reader.
Let’s have a look at a simple example. The following Java code will consume the XML generated above into an EmployeeBeen instance:
XMLInputFactory f = XMLInputFactory.newFactory(); XMLStreamReader sr = f.createXMLStreamReader(new FileInputStream(inputFile)); XmlMapper mapper = new XmlMapper(); sr.next(); // to point to <root> sr.next(); // to point to root-element under root EmployeeBeen employee = mapper.readValue(sr, EmployeeBeen.class); sr.close();
The XML module in Jackson is by no means designed to be an exact replacement for JAXB. There are certain constructs that will work subtly differently between JAXB and Jackson, and there is no guarantee that Jackson will produce identical XML to JAXB.
Note that, unlike with JSON, the outermost object must be a bean type – it can not be a primitive or wrapper type, an enumeration, or a collection. This is a direct result of how XML works – there’s no way in XML to represent such a top-level value.
By default, Jackson will always use a wrapper element for collections, which is also different to how JAXB works. This is the major way that the XML produced by Jackson is not compatible with the XML produced by JAXB. Of course, the behavior can be configured, using the JacksonXmlElementWrapper annotation for one field or the setDefaultUseWrapper configuration setting on the XmlMapper globally.
Jackson also has no support for working with specific XML Schemas. It’s designed for writing Java Beans first, rather than generating the Java code from pre-existing schemas. Note that this can be solved to an extent by using the JAXB annotation support and generating the beans using the standard xjc tool.
Equally, it has no support for some of the more advanced XML tools – such as XPath or XSLT. If we need this level of support then we should instead use a more full-featured XML solution.
In the mobile space, Jackson XML works perfectly well on Android. However, the StAX API is not included in the Android JVM, so it needs to instead be bundled manually.
If we’re using the Woodstox XML library that Jackson XML depends on by default – there’s nothing extra to be done. If, however, we’re using an alternative library – then we might need to add that dependency manually:
<dependency>
<groupId>javax.xml.stream</groupId>
<artifactId>stax-api</artifactId>
<version>1.0-2</version>
</dependency</span>
And for Gradle:
compile "javax.xml.stream:stax-api:jar:1.0-2"
If you’re looking for a mature, flexible way of supporting and working with both JSON and XML for the same data, the Jackson XML module is a fantastic library to leverage. It’s not only a solid way to go on its own, but it also has the added benefit of being able to mostly reuse the same configuration for both XML as well as JSON.
Typically, this has to be handled using two different libraries with entirely separate configurations.
Finally, beyond flexibility and ease-of-use, the Jackson team has historically placed a strong emphasis on performance. And given that marshalling and unmarshalling of data is a large part of most web applications, choosing the right library to handle all of that work is critical. That, plus a performance monitoring tool such as Retrace will allow you to get the most out of your app.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to stackify@stackify.com
