hasKey() or not

What are the challenge

1. Ambiguity. Ambiguity causes confusion, needs interpretation.

   i. Properties.containsKey() is from the HashTable interface whereas Properties.getProperty() recursively searches the contained "default" properties. Regardless of the actual implementation, it is ambiguous whether containsKey() should return true or false if the key only exists in the default properties.

   ii. A key for JSON config is viewed as a path to a JSON element. It is split into parts and walks down the JSON config part by part. Imagine a key is exhausted and you end up with a non-terminal JSON element. Does the key exist? Intuitively you would say true. But imagine the same key used on the same config but in the format of Java Properties. The key is clearly missing on that case.

2. Duplicate code and computation. To make hasKey() consistent with getVal(), hasKey() delegates to getVal(). However, getVal() throws ConfigEntryMissingException. A related question, if we have hasKey(), do we need the ConfigEntryMissingException?

What is the design

1. Lightweight, null-based ConfigReader
2. Whereas Config needs hasKey() for derived getAs...() methods.