Loading Persisted Null Values Into Objects with MyBatis

It almost makes sense: only invoke that setter if there's a value to invoke it with. But what about when a null value is meaningul? From org.apache.ibatis.executor.resultset.FastResultSetHandler:

  protected boolean applyPropertyMappings(ResultSet rs, ResultMap resultMap, List<string> mappedColumnNames, MetaObject metaObject, ResultLoaderMap lazyLoader) throws SQLException {
    boolean foundValues = false;
    final List<resultmapping> propertyMappings = resultMap.getPropertyResultMappings();
    for (ResultMapping propertyMapping : propertyMappings) {
      final String column = propertyMapping.getColumn();
      if (propertyMapping.isCompositeResult() || (column != null && mappedColumnNames.contains(column.toUpperCase(Locale.ENGLISH)))) {
        Object value = getPropertyMappingValue(rs, metaObject, propertyMapping, lazyLoader);
        if (value != null) {
          final String property = propertyMapping.getProperty();
          metaObject.setValue(property, value);
          foundValues = true;
        }
      }
    }
    return foundValues;
  }

A javabean with a default value for one of its properties certainly won't benefit from this logic. Ignoring the persisted null will lead to an improperly reconstituted instance where the getter will return the assigned default value instead of null—not particularly helpful. What are the alternatives?

Reconstitute via a specialized constructor

On the one hand, this is a good place to enforce proper state when bringing the instance back, and writing a test against this setup would be a walk in the park. On the flip side, this will get ugly real fast as the realization that 30 args is a few too many sets in. And the lack of named parameters in Java won't help make those tests any more readable.

Don't assign default values in Javabeans

Given that MyBatis facilitates the DTO approach, we could fully embrace the idiom and dumb classes all the way down. The silver lining here is that defaults can be fully externalized into configuration, producing cleaner code along that particular axis.

Patch the framework to call mapped setters unconditioanlly

Not for the faint of heart. This will result in an overarching maintenance commitment to a third-party library. Perhaps submitting said patch to the framework developers will yield a fruitful bounty and usher in a new utopia for other programmers around the world. Or perhaps I should get back to actually producing tangible results today.