[Feature Request][Pull request following] Support @AutoDefault for "required-key-but-not-required-value" behavior

[divyekapoor]

Hi Brian,
Thanks for making a fantastic config library. We (at Pinterest) have been using it extensively to set up our configuration infrastructure for our streaming applications.
One common pattern we have seen is that we often set up configs in the following manner:

code.java
interface ConfigIface {
  @Config("c")
  String getConfigInternal();

  default String getConfig() {
     if ("auto".equalsIgnoreCase(getConfigInternal())) {
       return "some-value-that-we-set-in-just-1-location-instead-of-50-configs-that-we-can-evolve";
     }
    return getConfigInternal();
  }
}

config.properties:
my.friendly.prefix.c=auto

The reason we do it this way is so that client teams know that the config actually exists (and can be overridden by them) but

The proposal is supporting this via a new annotation: @AutoDefault to make code like this:

interface ConfigIface {
  @Config("c")
  @AutoDefault("some-value-that-we-set-in-just-1-location-instead-of-50-configs-that-we-can-evolve")
  String getConfig();
}

config.properties:
my.friendly.prefix.c=auto

The difference with @Default is that the key is actually required in the config (so the configs all look the same and it's super clear where the framework is setting a value and where a user is setting a value). This is so common that we'd like to upstream it into the code so that we don't have to keep doing this.

Would you be open to accepting a pull request that implements this functionality?
It's a short change (10s of lines of code) - PR to follow.

[brianm]

My concern is having a hardcoded magic value, "auto" -- what do you think about my suggestion in the PR to make a change to @Default to specify that it should override certain values with the default value?

[divyekapoor]

Responded on the PR: #16 (comment)
Thanks for working with us!

[brianm]

Btw, the way I solved this discoverability problem in the past is just commenting out the unused config value. This takes it out of startup validation (a very valuable forcing function), but it worked for us.

[brianm]

Thank you, @sebastiananu for the PR! It should be merged, and released. I had to do a bunch of pokery-jiggery with maven and oss.r.o, but it looks like it went through in version 0.22, which is staged and should sync with central whenever it gets synced.