FAQ

Frequently Asked Questions

Why simply not use Config.hasPathOrNull and Config.getIsNull?

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 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 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.

Of course, people will always disagree about which units are used so often that they deserve their own methods, as oppose to just parsing the string value (e.g. Duration.parse(config.getString("timeout"))).

Why doesn't Optional Config not implement the Config 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 can be viewed as Config objects (such as ConfigObject.toConfig()), would have to be re-implemented to return OptionalConfig instead.

Second, if you go down that road, why not re-implement ConfigFactory as OptionalConfigFactory and so on.

Third, as discussed in the question above, either it would require the implementation of all getXXXX methods supported by the Config class, or you'd be throwing a multitude of UnsupportedOperationExceptions.

Basically, nowhere near the right power-to-weight ratio to do this.

What about using ConfigBeanFactory with the Optional annotation?

So this did give me pause when I started writing this library.

In the end it was clear that ConfigBeanFactory did not provide enough functionality.

Just as an example, even though I believe there is an existing PR, ConfigBeanFactory still throws an exception if a property is set to a null value. Which partly defeats the point of having optional values.

Did you know the Typesafe Config is no longer being maintained?

Yes. Or rather, that's not exactly true. Lightbend has indicated that they consider the project feature complete, and don't plan to make further changes, save for severe bugs or required updates when new Java versions are published.

There is talk about creating a community fork.

But this is still one of the best (imho), and widely used configuration libraries for the JVM.