-
-
Notifications
You must be signed in to change notification settings - Fork 230
Description
In the past it seemed like a good idea to try to make use of slight difference between logically equivalent cases of:
<root>
<empty/>
<start></start>
</root>
so that empty
would be automatically exposed as null
token; whereas start
element would have non-null empty String.
This was the behavior until 2.9
: 2.9 introduced FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL
to control whether this should be done or not: if disabled, both were equivalent, exposing them as start-end pair regardless.
This is more compatible with the logical content model of XML, but default was left as "enabled" for backwards compatibility.
However: with 2.12 there is much better support for various things:
- Exposing
xsi:nil
attributes for truenull
s (added in 2.10.0) - Allowing flexible coercions from empty String into "empty" POJOs, collections, maps
so it seems much more likely that users find defaulting of this setting to false
as the right behavior.
I realize that change in behavior can cause issues but in this case I think change is warranted: it is also what 3.0 is planned to use.