Transforming XML with null checks vs variables
I'd definitely go for the second version. If you are not in a very specific limited environment, the additional memory won't hurt. Note that you basically just copy the references to the concrete content, not the content itself, so the whole memory-signature-thing essentially revolves around a few 4-byte pointers.

As for the code itself: one way of coping with these long if a != null &amp;&amp; a.getB() != null &amp;&amp; a.getB().getC() != null chains is, to use Optional and its map function. In the end it's all matters of taste, but you might e.g. do:

// inner if from last code sample
Optional.ofNullable(subObject)
    .map(XmlSubObject::getLocation)
    .ifPresent(this::mapOtherStuff);


I like this style very much, but seriously: matters of taste.

One more thing: in similar situations I found it really helpful to include static utility functions which map from null to empty collection/list and vice versa:

public static &lt;T&gt; List&lt;T&gt; emptyListIfNull(List&lt;T&gt; l) {
  if(l == null)
     return new ArrayList&lt;T&gt;(); // or Collections.emptyList() if immutable is OK
  return l;
}

public static &lt;T&gt; List&lt;T&gt; nullIfEmpty(List&lt;T&gt; l) {
   if(l != null &amp;&amp; !l.isEmpty())
       return l;
   return null;
}


That way, you can shorten expressions like

xmlObject.getIdentifiers() != null &amp;&amp; !xmlObject.getIdentifiers().isEmpty()


to

nullIfEmpty(xmlObject.getIdentifiers()) != null


... which helps a lot in readability.

Edit: one more afterthought. As bowzerfood mentioned nulls and equals in his answer, I'd like to point out additionally, that today you can use Objects.equals(a, b) instead of a.equals(b) which handles nulls correctly and without resorting to third-party libraries.