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.

Comment From: 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?

Comment From: 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.

Comment From: 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          |
+-------------+--------------+-------------------+---------------+

Comment From: 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.

Comment From: 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).

Comment From: 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? 😅

Comment From: wilkinsona

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

Comment From: 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?

Comment From: wilkinsona

Gah! Sorry, I should have remembered that. The behaviour is intentional (see https://github.com/spring-projects/spring-boot/issues/5330). I think lower case and replace should be good enough.

Comment From: 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

Comment From: snicoll

Let's try to have another look still.