Hello!
I just had a long debugging session, until I noticed I had made a misspelling in a (property-id) string:
item.getItemProperty(“xyz1”), but should be item.getItemProperty(“xyz2”). In fact, my property doesn’t have any id named xyz1…
Well, I didn’t reflect on that at first, since I assumed that there will be an exception thrown if you are trying to aquire a Property from an Item with a no-go-ID. But I was wrong, and this is what Item.getItemProperty(Object) and PropertysetItem.getItemProperty() (that, for instance is extended by the BeanItem) tells me:
This means that whenever I misspell my property id (if using a string), the component I’m using will just seem to work normally - it won’t just display anything. In fact, since the property is null, setting the datasource to null will “clean it”. As the property-values often are null, you won’t even notice the difference between attaching the datasource with a property containing null versus setting the source itself to null (until you do a save :)). This may be a cumbersome issue to debug, so I suggest that whenever there is an attempt to fetch an item property using a non-existing id - throw an exception! In PropertySetItem.getItemProperty(Object id) we return the id from a hash map directly, which means we have to manually check if the properties are null. An irritating thing here, is that when a property contains a null-value, it looks, when inspecting the property in Eclipse IDE, also like the whole Property is null (which may go unnoticed).
This is just my point of view, and I’m sure there are some good arguments on why we return null instead of throwing an exception. Could someone enlight me on this one - Or are we in need of an API-change? 
BR,
Johan