What must the set of property names returned by Config#getPropertyNames() consist of?

The javadocs for Config#getPropertyNames() say, in their entirety, and I see no other language related to this topic in the specification documents:

Return a collection of property names. Returns: the names of all configured keys of the underlying configuration.

It is hard to know what to make of this. Does this mean:

1. The set of property names returned by Config#getPropertyNames() must consist only of the combination of the sets of property names returned by each ConfigSource present in the return value of Config#getConfigSources() and nothing else
2. The set of property names returned by Config#getPropertyNames() may contain a subset of the combination of the sets of property names returned by each ConfigSource present in the return value of Config#getConfigSources()
3. The set of property names returned by Config#getPropertyNames() can be anything the implementor wants, regardless of whether it is represented in part or in whole by any ConfigSource notionally contained by the Config …? It must be one of these. The specification does not say, and there is no TCK test.

I am assuming that (1) is the proper answer (modulo any information related to #370). However, given that the specification says nothing and there is no TCK¹, (3) is the de facto answer at the moment.

If (1) is the proper answer, should a TCK test exist for this?

If (1) is not the proper answer, why does this method exist?

¹ There is https://github.com/eclipse/microprofile-config/blob/828ee2fee4ccbef6701943bb96d7be187408fd63/tck/src/main/java/org/eclipse/microprofile/config/tck/ConfigProviderTest.java#L170-L183 which indirectly tests only that Config#getPropertyNames() must contain at least one key returned by the getPropertyNames() methods of the ConfigSource instances returned by getConfigSources() at the moment of the Config#getPropertyNames() call.

[OndroMih]

I see there’s a usecase for ConfigSource.getPropertyNames in some cases, especially during initialization. However, we should ensure that the result is not constant and shouldn’t be cached for a long time. I’m not sure this is ensured now, os it? ConfigSources can be mutable and new properties can be added dynamically, so thry don’t know the list of all their props at initialization. There are also good usecases to support completely dynamic sources that derive the value for some properties from their name, so a new property can be created as late as an app asks for it.

If we deprecate getProperties and later remove it, we could change the default impl for getPropertyNames to return an empty set. This would indicate that it’s OK to return an empty set of properties and still provide values later. Expensive config sources could decide to return an empty or incomplete set of property names and still work.

Even if we leave getProperties, we can provide a default impl that returns an empty set.

I would also consider how calling getPropertyNames/getProperties can slow down the app. If we allow configsources to return an empty/incomplete set of props and still provide more values later, that might solve this problem too.

[dmlloyd]

I guess everyone did; no worries 😃

@Emily-Jiang I think this means that there is no further reason to prevent deprecation of ConfigSource#getProperties() for removal as @jmesnil has proposed.