Config.getValue and ConfigValue.getValue

[Emily-Jiang]

The javadoc on Config.getValue() and ConfigValue.getVaue() are inconsistent.

config.getValue() https://github.com/eclipse/microprofile-config/blob/master/api/src/main/java/org/eclipse/microprofile/config/Config.java#L108

/**
     * Return the resolved property value with the specified type for the specified property name from the underlying
     * {@linkplain ConfigSource configuration sources}.
     * <p>
     * The configuration value is not guaranteed to be cached by the implementation, and may be expensive to compute;
     * therefore, if the returned value is intended to be frequently used, callers should consider storing rather than
     * recomputing it.
     * <p>
     * The result of this method is identical to the result of calling
     * {@code getOptionalValue(propertyName, propertyType).get()}. In particular, If the given property name or the
     * value element of this property does not exist, the {@link java.util.NoSuchElementException} is thrown. This
     * method never returns {@code null}.
     *
     * @param <T>
     *            The property type
     * @param propertyName
     *            The configuration property name
     * @param propertyType
     *            The type into which the resolved property value should get converted
     * @return the resolved property value as an instance of the requested type (not {@code null})
     * @throws IllegalArgumentException
     *             if the property cannot be converted to the specified type
     * @throws java.util.NoSuchElementException
     *             if the property is not defined or is defined as an empty string
     */

ConfigValue.getValue()

/**
     * The value of the property lookup with transformations (expanded, etc).
     *
     * @return the value of the property lookup or {@code null} if the property could not be found
     */

I think ConfigValue.getValue() should behave the same as Config.getValue(). The other thing is that ConfigValue.getValue() always return a string. Should we pass a calss type as the parameter and return the same type? If not, we should rename the method getStringValue instead.

[radcortez]

Well, we had that discussion about passing the type to provide conversion, but if I remember correctly, we decided to go simple with the API and add it later. If that changed, we can add it now.

I'm not completely sure if ConfigValue should follow the same rules and getValue, mostly because ConfigValue is a container object much like Optional, so I think it should work as an Optional.

Also, the idea is that we enhance ConfigValue with additional API's and information. I think that if we introduce that restriction, we may be limiting ourselves with what we can do with it later. For instance, we could add some debugging information that details the config lookups. The config might even exist in a lower ordinal source, but emptied in a higher source. Or we can even collect all the available values in all sources for the user to decide which one to use based on some logic. If we just fail the lookup then we cannot provide such enhancements.

[Emily-Jiang]

@radcortez Thanks for the explaination! Maybe we should just change the method getValue to getStringValue() to reflect this purpose and later on we can make getValue to return something being converted. It is good to revisit and see whether it makes us confused. Thoughts?

[radcortez]

I guess it depends how you see it. Since the spec is all about Strings, and the original format is a String, I'm find with getValue returning a String for ConfigValue, but I don't oppose to rename it.

My idea was to add a getAs(Class) method that would perform the conversion to the specified type.