Add support for enum default values in configuration processor

[qerub]

It's quite common to use enums for configuration properties, but the configuration processor is currently unable to extract the default value for those (because of lack of support in JavaCompilerFieldValuesParser). This means that the generated configuration JSON specification is currently incomplete/incorrect wrt. to enum properties. Unless this functionality has been left out on purpose I can take a stab at adding it.

[snicoll]

This is something that can be extracted from code and the IDE is supposed to do that for you. I am not keen to write such duplication in the metadata.

Why are you asking for this? Which IDE do you use?

[qerub]

I use IntelliJ IDEA but the wish for this came up outside the context of an IDE when trying to use the configuration meta-data to generate documentation describing all properties and their default values.

[qerub]

For example, I was hoping to generate tables with default configuration using jq:

cat **/spring-boot-sample-property-validation/**/spring-configuration-metadata.json | \
jq -r '.properties[] | [.name, .description, .type, .defaultValue | tostring] | @csv' | \
csvfix ascii_table -h "Name, Description, Type, Default value"

+-------------+--------------+-------------------+---------------+ 
|    Name     | Description  |       Type        | Default value |
+-------------+--------------+-------------------+---------------+
| sample.host | Sample host. | java.lang.String  | null          |
| sample.port | Sample port. | java.lang.Integer | 8080          |
+-------------+--------------+-------------------+---------------+

[wilkinsona]

It sounds to me like there's some confusion here between listing all possible values for a property with an enum type (which an IDE can do automatically) and listing the default value for such a property.

In our own metadata I'd expect there to be a default value listed for security.headers.hsts but there is not:

{
    "name": "security.headers.hsts",
    "type": "org.springframework.boot.autoconfigure.security.SecurityProperties$Headers$HSTS",
    "description": "HTTP Strict Transport Security (HSTS) mode (none, domain, all).",
    "sourceType": "org.springframework.boot.autoconfigure.security.SecurityProperties$Headers"
},

This means that the IDE (I checked in IntelliJ) doesn't display a default value. It does, however, list the three possible values as completion options having extracted them from the enum.

[snicoll]

Wow, for some reason my brain read "list of values" instead of default value. Thank you @wilkinsona for pointing that mistake.

Yes, we should try to improve this. If you want to give that a try, please note we use a canonical representation for as much content as we can (my-super-long-property). IDEs have harmonized to that, offering you the canonical representation of the enum value.

Clearly, it means the same work should be done when detecting MY_VALUE (and writing my-value in the metadata).

[qerub]

Clearly, it means the same work should be done when detecting MY_VALUE (and writing my-value in the metadata).

Is there a built-in function somewhere in Spring [Boot] I can use to do this conversion?

…or is it OK that I use the function ->kebab-case from my Clojure library https://github.com/qerub/camel-snake-kebab? 😅

[wilkinsona]

@qerub ConfigurationMetadata.toDashedCase(String) should be able to do that for you.

[qerub]

@wilkinsona: Just checked toDashedCase and it doesn't treat NAMES_OF_CONSTANTS like we need (e.g. VERY_SLOWbecomes v-e-r-y-s-l-o-w). In this context of enum names, is it good enough to lowercase and replace _ with - or do we need handle non-idiomatic names as well?

[wilkinsona]

Gah! Sorry, I should have remembered that. The behaviour is intentional (see #5330). I think lower case and replace should be good enough.

[snicoll]

As discussed in #7593 there isn't a definitive way to know that the symbol represents an enum when we are looking for the default value. This could lead to false positive in the metadata so we recommend to use manual metadata for those. I'll update the documentation in #7890

[snicoll]

Let's try to have another look still.