Fix for #162 (XML Empty tag to Empty string)

[oistein]

Fix for issue #162.

[oistein]

Any updates on this?

[Mo-la-machette]

Hello everyone ! Is this pull request going to be merged soon? thank you

[cowtowncoder]

Hmmh. Why? This was an optimization for the common case of just single segment, in which case construction of intermediate StringBuilder was avoided. It's probably not a big deal either way, but usually I prefer not fixing things that ain't broke.

[cowtowncoder]

Oh. Actually, I see. So, this was to get empty String over null.
I think I'll modify this bit differently, after first merging,.

[cowtowncoder]

Ok, I am really torn here. The challenge here is this: fix changes low-level behavior, regardless of what target type might be. This means that it could change handling of empty/null cases for any number of other scalar types; here we'd prefer only changing String case (which I think should ALWAYS get to empty String). In addition, distinction between empty XML element and start/end should not have any significance, from XML perspective: logically the two are equivalent.

Still.. I think I'm ok for trying this out for 2.9.0, and see if it works better than before. I may be sorry (I've had a few similar-looking cases that burnt :) )... but we'll see.

[cowtowncoder]

Ended up implementing #245 and #246 that should help here: so, by default empty element (but NOT start+end with no content) will be exposed as JsonToken.VALUE_NULL. But this may changed via FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL to instead return JsonToken.VALUE_STRING (with text of "").
Enabling this feature is likely most natural way to deal with XML content, and doing that will also help with things like "empty" Objects (instead of null reference).

[mliberty]

It would be nice to also have a way to make start+end with no content deserialize to null, especially since that was previous behavior.

[cowtowncoder]

@mliberty these combinations are bit of a mess. But I didn't think start+end did deserialize to null previously?

I am now bit torn as to whether to also add matching feature for START+END; but that should go in 3.0.

Also, there seem to be (at least?) 3 distinct possibilities for both:

1. Expose as "native" null
2. Expose as empty String value ""
3. Exposes as logical START_OBJECT/END_OBJECT

all of which make sense for some use cases.

Although due to wide variety of coercions available, perhaps (3) is not needed: it is bit trickier to support (need to emit 2 tokens; will confuse functionality at databind level).

[cowtowncoder]

Unfortunately with 2.x there is no way to make all cases work well: it would be easy enough to induce null for start+end, but that would probably break some code that expects empty String.
With "null coercion" many things are possible, but in patch release such functional changes should not be added.

3.0.0 will now implement this, however, as suggested.