Question

I have written a JAXB mapping that stored a sublist inside a root element in a LinkedHashMap<String, Object> instead of a Collection<Object> maintained through a specific XmlJavaTypeAdapter. Hereunder a sample:

@XmlRootElement
public class Parent {
    @XmlJavaTypeAdapter(ListToMapAdapter.class)
    @XmlElement
    private LinkedHashMap<String, Child> children;

    ...
}

The key is built from the attributes of the child tag (e.g. <child id="key"> give a Map.Entry<String, Child> like {key => child}.

One of my coworker says its bad designed, and that this Map should be in the object in charge of unmarshalling the XML. I’m not agree with him. Here are some pros and cons on such an approach. Which design do you think is the best? And which pros and cons did you see to complete the debate?

Goal of this design:

• the Map give the ability to search efficiently children with a criteria (the key in my sample) instead of search by iteration on a Collecion.

Pros:

• responsability for searching and filtering the sublist is at the nearest of the object and the parent object is responsible of retrieving and filtering its child,
• the building of the Map is automatically made by JAXB when unmarshalling: elegant, efficient, and preserve from building the Map with a post process of the list after umarshalling (iteration),
• the same object in different readers has still the ability of filtering its children,
• subjective, it’s really a pretty way of doing that :),
• if @XmlJavaTypeAdapter exists, it’s partly for this (numerous samples of this on the Web).

Cons (some are from my coworker):

• JAXB limitation constraints to code to a concrete implementation instead of an interface: could not declare Map<String, Child> in my sample (not instantiable by JAXB while unmarshalling),
• maybe (and its the argument of my coworker), its not the role of a mapping object (simple POJO according to him) to have such a behavior,
• @XmlJavaTypeAdapter aims only at converting simple object to specific types: xs:date to Joda time Calendar for instance.

Thanks in advance for your 2 cents.

Answer 1

I always recommend that people design the best model possible for their application. Then let JAXB handle the difficulty of mapping it to XML. In this case if it makes sense for parent to have a Map of children then by all means model it this way. JAXB does have some support for Map, but with the XML representation you describe you will need to use an XmlAdapter. For more information see:

• http://bdoughan.blogspot.com/2010/07/xmladapter-jaxbs-secret-weapon.html

All of the Pros seem reasonable. None of the cons are valid:

• As you can see from the above example when using @XmlJavaTypeAdaper your property is NOT restricted to a concrete implementation of Map.
• The XmlAdapter is external to the POJO model, so the model does not have the list to/from map behaviour.
• XmlAdapter is meant to be a catch all for any hard to map use case. It is not restricted to only simple objects. A common use case is for mapping instances of Map.

If you want to eliminate the wrapper element, then you can use the @XmlPath extension in the MOXy JAXB implementation. The Foo class from my blog article would be modified slightly:

import java.util.HashMap;
import java.util.Map;
import javax.xml.bind.annotation.*;
import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter;
import org.eclipse.persistence.oxm.annotations.XmlPath;

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Foo {
    @XmlJavaTypeAdapter(MyMapAdapter.class)
    @XmlPath(".")
    Map<Integer, String> map = new HashMap<Integer, String>();

    public Map<Integer, String> getMap() {
        return map;
    }

    public void setMap(Map<Integer, String> map) {
        this.map = map;
    }
}

For more information see:

• http://bdoughan.blogspot.com/2010/07/xpath-based-mapping.html
• http://bdoughan.blogspot.com/2010/09/xpath-based-mapping-geocode-example.html