Convert environment variables to properties support

[Reed Chan]

Generally, environment variables format are different from system properties format, for example: FOO_BAR in environment variable and foo.bar in property. My highest priority of load strategies is system:env, so if I want to override a property I have to define an environment exactly equals to the property, which means foo.bar in env and foo.bar in property.

Now I want to define the env as FOO_BAR not foo.bar, could u support this feature? I think this would make the load strategy smarter :)

[Alexei Khatskevich]

There is no any general specified format for system properties or environment variables names. You can use whatever you want, from what is accepted by e.g. your OS. Yes, java.lang.System support set of "default" system properties in form "x.y.z" (e.g. java.version), but this is specific of this class, and not general & cross-platform rule.

So, I am personally, see this proposal as a very specific use case, which should not be supported in the library by default.

BUT. What you can do, is to implement you own loader, which is merge system:env & system:properties with renaming you wish. It's easy to do actually. Look at org.aeonbits.owner.loaders.Loader interface & org.aeonbits.owner.Factory.registerLoader method.

[Reed Chan]

There is no any general specified format for system properties or environment variables names. You can use whatever you want, from what is accepted by e.g. your OS. Yes, java.lang.System support set of "default" system properties in form "x.y.z" (e.g. java.version), but this is specific of this class, and not general & cross-platform rule.

So, I am personally, see this proposal as a very specific use case, which should not be supported in the library by default.

BUT. What you can do, is to implement you own loader, which is merge system:env & system:properties with renaming you wish. It's easy to do actually. Look at org.aeonbits.owner.loaders.Loader interface & org.aeonbits.owner.Factory.registerLoader method.

@Gmugra OK, I got it. Thanks for your help, I'll try to implement my own loader. 🤔

[Serhii Korol]

My 50 cents: I haven't ever seen anyone used env variables in a format other than uppercase words separated with underscores. Moreover, I haven't seen any tools which use the other format for their env vars. Even Google suggests using this format in their style guide. That's why I was very surprised and confused to see that @Key ignores my env variables specified in ENV_NAME format.

[Alexei Khatskevich]

@sskorol
I'm not quite sure what you mean by that.
e.g. this is working just fine:

@Sources("system:env")
public interface MyConfig extends Config {

    @Key("JAVA_HOME")
    String javaHome();
}

OWNER has no problem reading env variables with any name.
The problem @juan-chan encountered is about an exotic merging strategy between system:env and system:properties

FYI:
Unfortunately, OWNER is not really supported anymore.
@lviggiano multiple times wrote that he has no time for the project anymore.
New PRs are factually ignored.
So, there's not much point in waiting for new features. Unfortunately.

This OWNER situation has been a problem for me, so I've been developing an alternative with a similar API for some time now. Check it out. It might be more suitable for you. At least it in active developing and support.