Mark Waschkowski wrote:
...
Fair enough. However, look at it from the reverse point of view, what would
the impact to the users of the API be if setting a property to null DIDN'T
remove it (assuming there was a flag that could be set to toggle the
behavior on startup to deal with compatibility issues)? The existing
remove() function would then be used to remove properties when not desired,
instead of setting properties to null and having this side-effect. I believe
that the API would be more intuitive to most, if not all users, the
workarounds that we have developed wouldn't be required, and that nobody
> ...
Again:
the thing that's being proposed is not an API change, but a data model
change.
If we stick with the current data model (which I'd support), then
passing a null value can either cause an exception, or cause the
property to be removed. I don't have a preference here, except for
keeping compatibility with JSR-170.
If you want to discuss a data model change, please be clear about it,
and stop discussing the API. What the API does depends on the data
model, not the other way around.
Best regards, Julian
