Hi Tako, I wasn't comparing Hashmap to JCR, just stating an API that many people would be familiar with and its use of nulls. Again, the most obvious example is that variables in java can be set to null, and that has meaning. ie. its null. the variable exists, and is set to a null value
"What would you do with a mandatory property for example? Will you allow it to contain a null value? I think not because I would expect a mandatory property to hold a "real" value." Again, this is about the behavior mandated by the spec - setting a property to null deletes the property as a side effect. With regards to a mandatory property, the way I would expect JCR impl is to throw an exception if a node was attempted to be saved and a mandatory property wasn't set. Certainly null could be handled as well as no value. "But if it can't contain null isn't it in fact exactly the same as not having the property at all? By definition you'd have to extend this idea to non-mandatory properties as well because if we think the current situation (where setValue(null) is the same as a remove()) is confusing think about a system where mandatory and non-mandatory items have different semantics!" It would be actually pretty darn straightforward - if a mandatory value doesn't exist or is null when saving, then throw an exception. Again, in Java having a variable set to null is a valid state, and it could certainly be so in JCR. I'm surprised that its not, and would like to see it changed. I don't want to beat a dead horse here, but as Alexandru has stated 'almost everywhere' (in the java space anyway), the semantic difference between setValue() and remove() is respected in most java apis, probably because the language itself works that way. Regardless, what do you think - does having remove() and setValue(null) both remove a property make sense to you? Or are you more concerned with the ramifications of what other changes would have to be made to accommodate changing the spec as the OP suggests? Best, Mark
