I like SmallRye Config and I feel it's designed this way because of the problems it tries to solve. The following is an excerpt from the MicroProfile Config sta

I like SmallRye Config and I feel it's designed this way because of the problems it tries to solve. The following is an excerpt from the MicroProfile Config standard which SmallRye Config is an implementation of: > The majority of applications need to be configured based on a running environment. It must be possible to modify configuration data from outside an application so that the application itself does not need to be repackaged. > The configuration data can come from different locations and in different formats (e.g. system properties, system environment variables, .properties, .xml, datasource). We call these config locations ConfigSources. If the same property is defined in multiple ConfigSources, we apply a policy to specify which one of the values will effectively be used. > Under some circumstances, some data sources may change dynamically. The changed values should be fed into the client without the need for restarting the application. This requirement is particularly important for microservices running in a cloud environment. The MicroProfile Config approach allows to pick up configured values immediately after they got changed. One reason we don't know whether SmallRye Config is reading from a file or querying a database at development time is because that choice has been deferred to the system administrator at deployment time. Records are immutable. If we want to be able to reconfigure applications at runtime it might make sense to use a mutable data structure. You can load configuration programmatically if don't want to use dependency injection and/or want something that is easier to test. See https://download.eclipse.org/microprofile/microprofile-config-2.0/microprofile-config-spec-2.0.html#_simple_programmatic_example https://download.eclipse.org/microprofile/microprofile-confi....