FAQ

Frequently Asked Questions

Why simply not use [Config.hasPathOrNull](https://lightbend.github.io/config/latest/api/com/typesafe/config/Config.html#hasPathOrNull-java.lang.String- target="_blank") and [Config.getIsNull](https://lightbend.github.io/config/latest/api/com/typesafe/config/Config.html#getIsNull-java.lang.String- target="_blank")?

If you used hasPathOrNull or getIsNull directly, you would have to write a good amount of boilerplate code for each optional property. Chances are you'd end up making some utility methods along the way, which is how this library started.

Even then, you'd quickly realize the helper methods don't easily handle more complex cases.

So basically why not just do it right?

How do you deal with default values set in reference.conf, environmental variables, or Java system properties?

There is nothing to deal with. Optional Config has no opinion on how the underlying [Config](https://lightbend.github.io/config/latest/api/com/typesafe/config/Config.html target="_blank") resolves its properties.

Why does Optional Config not implement all the getXXXX methods from the Config class? For example getDuration?

This was a design choice. In generally it stems from my philosophy that methods such as [Config.getDuration](https://lightbend.github.io/config/latest/api/com/typesafe/config/Config.html#getDuration-java.lang.String- target="_blank") should conform to the JDK conventions. In which case, without passing a formatter, only ISO-8601 values (such as PnDTnHnMn.nS) should be parsable by default. And, of course, people will always disagree about which units are used so often that they deserve their own methods, as oppose to Duration.parse(config.getString("timeout")).

Why doesn't Optional Config not implement the [Config](https://lightbend.github.io/config/latest/api/com/typesafe/config/Config.html target="_blank") interface?

I thought about this, but it would be highly prohibitive. First of all, it would be a lot of effort to implement correctly, while offering little practical utility. All methods that return Config objects, and all methods that return objects which themselves have methods to convert them to Config objects (such as ConfigObject.toConfig()), would have to wrap them in OptionalConfigs. Second, as discussed in the question above, either it would require to re-implement all getXXXX methods supported by the Config class, or throw a multitude of UnsupportedOperationExceptions.

What about using [ConfigBeanFactory](https://lightbend.github.io/config/latest/api/com/typesafe/config/ConfigBeanFactory.html target="_blank") with the [Optional](https://lightbend.github.io/config/latest/api/com/typesafe/config/Optional.html target="_blank") annotation?

So this did give me pause as I started writing this library. In the end it was clear that ConfigBeanFactory did not provide enough functionality. For example, even though I believe there is an existing PR, it still throws an exception if a property is set to a null value. Which partly defeats the point of having optional values.