The hope is that we could avoid problems like https://github.com/spring-projects/spring-boot/issues/28037. In that case there's a List<String> property with a default value created with new ArrayList<>("…"). The annotation processor can't extract the default value so we rely on an entry in the manual metadata for it. For such a property that doesn't have an entry in the manual metadata, it'd be good if the annotation processor could fail or generate a warning.

Comment From: onobc

I too could have used this protection here.

Comment From: onobc

I was sad when I dug in and discovered that the config annotation processor was not an actual magic lamp that created magic metadata for me but instead was just some code written by humans that can handle only a limited set of default value types. ;)

But all kidding aside, I am interested in working this one @wilkinsona if its up for grabs. I have not yet done anything in the way of the annotation processors yet (other than figure out how to step through debugger during compile step.

~~If so, I have some questions before moving forward. I see the following options:~~

~~### Option 1 - fail~~

~~If there is an initializer expression but the default turns out null(eg. new ArrayList<>("…")) then fail. This could be done directly in the FieldValuesParser implementation.~~

~~### Option 2 - warn If there is an initializer expression but the default turns out null (eg. new ArrayList<>("…")) then log warning. We could just catch the the exception thrown from option 1 and handle it by log warning rather than letting it bubble up.~~

~~### Option 3 - ability to configure fail or warn Variation of the above where the "warn lever" of option 2 is used (or not) based on config prop. I am not sure if this is desirable NOR how to set configuration properties for annotation processors.~~

~~Thoughts?~~

I dug deeper and the above options/questions sort of fell out as I learned more about how the processor works and where it logs warnings currently. I will tidy up what I have tomorrow and submit.

Comment From: wilkinsona

Having seen #28062, we're not sure that this is a good idea. We'd like the explore some alternative approaches such as:

  • improving the default value extraction in the annotation processor
  • using a new annotation that allows a default value to be specific on the configuration properties class rather than it being separated out into the addition metadata json file