Skip to content

FAQ

Jump to bottom
zleonov edited this page Dec 1, 2023 · 29 revisions

Frequently Asked Questions

Why not simply 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 JDK conventions. In which case, without passing a formatter, only ISO-8601 values (such as PnDTnHnMn.nS) should be parsable by default.

I am also not sure about the utility of such methods as opposed to just parsing the string value. Of course, people will always disagree about which units are used so often that they deserve their own methods.

Why doesn't the OptionalConfig class 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 (e.g. ConfigObject.toConfig()), would have to be decorated to return OptionalConfig instead.

Second, if you go down that road, why not decorate 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 using ConfigBeanFactory did not provide enough functionality.

As an example, ConfigBeanFactory (even though I believe there is an existing PR for this) still throws an exception if a property is set to a null. Which partly defeats the point of having optional properties. Also it's extremely cumbersome to have the Bean class return Optional values since ConfigBeanFactory only recognizes beans that abide by the JavaBeans conventions.

What is the utility of allowing null values in lists?

Good question. Outside of storing test data for unit tests there is probably little utility in allowing null values in properties referencing lists of values. And this is one of those questions where it's not clear if the utility of the feature outweighs a user's ability to accidentally shoot themselves in the foot.

But that's why in order to process null values you have to explicitly call OptionalConfig.setStrictMode(false).

Why did you re-implement getEnumList as getEnumSet?

The main use case for a collection of enum elements is to represent a bitmask in a Java idiomatic way. A Set implementation for use with enum types is so ubiquitous in Java, it seems hard to imagine a use case where you actually want duplicate enum elements in a list. In this case I'd rather be more specific than less.

What about implementing an analogous Config.checkValid method?

The purpose of the Config.checkValid method is to fail-fast with a complete list of missing or incorrect properties as opposed to failing one by one downstream.

Unfortunately, correctly implementing this functionality is a losing proportion. To implement this method correctly you need a full-blown schema validator which doesn't exist for Typesafe Config or the informal HOCON specification.

Consider a property with an enum value weekday = MON which is referencing an enum Day { SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY }. There is no way for the validation method to know that the correct property should be weekday = MONDAY. What about an Integer value that cannot be negative? And so forth.

This is further complicated by supporting optional properties. You would have to implement some kind of TypeToken functionality to overcome Java's type erasure (In Java there is no way to know that an Option<String> is different from an Optional<Integer> at runtime).

The best this method can do is validate whether or not the required properties exist. It can never ensure the correctness of a domain-specific configuration. In the end this functionality doesn't pull its own weight, it's always optional since you are guaranteed to fail-later soon enough.

Of course, it's easy enough for developers to create a validation method on top of OptionalConfig for their specific domain.

What about automatically populating a bean class from an OptionalConfig like ConfigBeanFactory.create?

I think this may be a feature request. I am thinking of implementing this for the next version.

But again, I have serious doubts of the utility of this functionality, given the pattern in which OptionalConfig can be used. Consider the OptionalConfig.at method which allows users to view any nested configuration object as standalone OptionalConfig.

I am just not sure I see a lot of difference between final String firstName = conf.getString("first.name") vs. final String firstName = person.getFirstName().

To implement this feature correctly, without a third party library like Apache Commons BeanUtils, would require quite a lot of effort.

Did you know Typesafe Config is no longer 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 also talk of creating a community fork.

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

Clone this wiki locally