Reading section III, I see it specifically calls out the value in avoiding on-disk property files and named per-environment groupings of properties as non-scalable anti-patterns. I don't know whether or not I agree with that, but I am curious why you're claiming to be inspired by that section when, by and large, the only thing that seems to align with what's described in section III is not hardcoding the property values directly in code, which isn't really specific to the twelve factor methodology.

Definitely! There's no limit on what configuration formats Externalized Properties can support as you can implement custom `Resolver`s to retrieve from any source and format e.g.

    public class PklResolver implements Resolver {
        public Optional<String> resolve(InvocationContext context, String propertyName) {
            return getFromPklConfig(propertyName);
        }
    }


    // Register custom resolver when building ExternalizedProperties

    ExternalizedProperties externalizedProperties = ExternalizedProperties.builder()
        .resolvers(new PklResolver(...))
        .build();

    AppProperties appProperties = externalizedProperties.initialize(AppProperties.class);

    // Resolves config from PklResolver

    String myConfig = appProperties.myConfig();

It's more performant than other similar libraries such as the Owner and cfg4j which no longer seems to be actively developed at this point and others such as Spring's Environment and MicroProfile config implementations

See benchmarks here: https://github.com/joel-jeremy/java-config-library-benchmark...

Aside from the performance, the other advantage of using this config library is how it makes testing easier and how easy it is to integrate with your dependency injection frameworks of choice.