You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 true nulls (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.
The text was updated successfully, but these errors were encountered:
cowtowncoder
changed the title
Change default setting of FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL
Change default setting of FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL from true to falseJun 5, 2020
In the past it seemed like a good idea to try to make use of slight difference between logically equivalent cases of:
so that
empty
would be automatically exposed asnull
token; whereasstart
element would have non-null empty String.This was the behavior until
2.9
: 2.9 introducedFromXmlParser.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:
xsi:nil
attributes for truenull
s (added in 2.10.0)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.
The text was updated successfully, but these errors were encountered: