This issue came up in a Spring Boot context.
Since DefaultProgrammaticDriverConfigLoaderBuilder is based on NullAllowingImmutableMap, the map builder would reject any duplicate keys.
This may be too restrictive for systems where various independent components all get a chance to enrich the config with more settings, with some potential overlap.
Granted, if duplicate keys are allowed we open the door for non-deterministic behavior. But I'd argue that 1) this is already the case with the OptionsMap API – and 2) application correctness is not a driver concern after all.
I think we should also deprecate DefaultProgrammaticDriverConfigLoaderBuilder. DriverConfigLoader.fromMap is a better alternative, but the message has not been communicated clearly enough.
Agreed, with and both solved, indeed it seems natural to deprecateDefaultProgrammaticDriverConfigLoaderBuilder and evangelize around DriverConfigLoader.fromMap as a better alternative.
Hmm thinking about this a bit more, I think deprecation is a bit overkill. Users may want to override a few options programmatically while still keeping the TypeSafe Config machinery around, for example to apply system properties overrides and/or to use a common application.conf file with the most common options that never change.
These use cases seem valid to me and I don’t think it’s legit to deprecate them.
I'm going with the simplest solution that would allow to unblock the Spring Boot issue – even if Spring Boot would be an excellent candidate for switching to OptionsMap, but that's a bigger change that won't be implemented soon.