Bean property with null values? (+ general bean mapper usability thoughts)

[ljacqu]

I don't know if I want to allow this, but it might make sense to have an option in the mapper to allow fields to be null. Right now, if you use bean properties with ConfigMe, you have to understand very well what needs to happen in order for a new field to be added, without that the user loses all data:

• need to probably define a copy of the class with any new fields as Optional
• in the migration service, load property as that and replace any Optional.empty with a value
  -> this only saves the new values to the config file, but the actual bean property is already converted and used in the application, i.e. for proper migration, also this:
• convert from the class with Optional to the current bean class and set that value as the bean property

I don't think there's a way to reduce the number of steps, but it would make sense to maybe have a method on the mapper that can create objects with a null field? Then we wouldn't need to maintain a copy with Optional-typed fields.

Ultimately, also for bean property values, if a user wants to have null values, I still think it's not in the philosophy of ConfigMe, but there's also no point in standing in the way of that. It still doesn't break the core ConfigMe philosophy since the bean itself is never null (but one of its fields might be...)

[ljacqu]

Similar findings were shared in #396