The output of the spring-boot-configuration-processor looks like below. It can't determine the names of any arguments. Those classes are standard classes with all final fields, annotated with lombok's @Data.

The issue only happens if the constructor is created by lombok and the class is annotated with @ConstructorBinding. If I create the constructor by hand, then it all works just fine. If I make the class mutable and remove @ConstructorBinding, it also works fine, even with a lombok-generated constructor.

{
  "groups": [
    {
      "name": "config.processor",
      "type": "io.app.config.ProcessorConfig",
      "sourceType": "io.app.config.ProcessorConfig"
    },
    {
      "name": "config.sender",
      "type": "io.app.config.SenderConfig",
      "sourceType": "io.app.config.SenderConfig"
    }
  ],
  "properties": [
    {
      "name": "config.processor.arg0",
      "type": "java.util.Map<java.lang.String,io.app.config.ProcessorConfig$InnerClasss>",
      "sourceType": "io.app.config.ProcessorConfig"
    },
    {
      "name": "config.sender.arg0",
      "type": "java.lang.Boolean",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg1",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg2",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg3",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    },
    {
      "name": "config.sender.arg4",
      "type": "java.lang.String",
      "sourceType": "io.app.config.SenderConfig"
    }
  ],
  "hints": []
}

Comment From: snicoll

@andrebraitc thanks for the report, I was able to reproduce it. I've debugged things a bit and I can see the model Lombok gives us contain arg0 and the like unfortunately.

When a @ConstructorBinding is present, we switch to pure reflection mode. If we want to infer what Lombok is going to do (as we do for regular accessors) we'd have to infer what the constructor should be, meaning looking at final fields and those who have a non-nullable constraint on them as RequiredArgsConstructor states. I am tempted to go best effort and just look at final fields.

Comment From: wilkinsona

I wonder if it's worth raising a Lombok enhancement request to generate parameter names that are more meaningful than arg0 etc. It could, presumably, reuse the field names to which the constructor's parameters are going to be assigned.

Comment From: snicoll

Something else to mention is that if any property requires a default value, you'll have to generate the constructor anyway to provide it using @DefaultValue.

Comment From: snicoll

@wilkinsona I agree but that suggestion would only work if Lombok ran before us. Our lombok support doesn't have that assumption at the moment, it reads the lombok annotations and infer what lombok will do, ignoring whether the actual bytcode has been produced or not. This very example is a bit more involved unfortunately as we'd have to infer what the constructor would look like.

Comment From: wilkinsona

would only work if Lombok ran before us

That seems like a reasonable requirement for us to introduce in a new minor release. As I understand it, it would remove a lot of complexity from the annotation processor and also remove the risk of our understanding of what Lombok will do getting out of sync with what Lombok actually does.

Comment From: andrebrait

I deleted my other GitHub account. Contact this account if you need. As for the issue itself, I would think a lombok improvement would be in order, too.

However, I'm not sure you can do an annotation processor that assumes another has already run before it, can you? Perhaps something that would attach itself to a different build phase than the other annotation processor?

Comment From: snicoll

I've created https://github.com/rzwitserloot/lombok/issues/2275

Comment From: wilkinsona

This has hopefully been addressed in Lombok by a combination of https://github.com/rzwitserloot/lombok/pull/2497 and https://github.com/rzwitserloot/lombok/pull/2556. The changes aren't in a release yet.

Comment From: snicoll

I've tested a snapshot of the lombok build and I confirm that the issue is fixed.

Comment From: dan-lind

I case anyone else stumbles upon this - I updated lombok to 1.18.16 and still faced issues, spring now didn't output any field data at all when I had my class annotated with

@Value
@ConstructorBinding
@RequiredArgsConstructor
@ConfigurationProperties

Turns out the order in which annotation processors are defined (in my case in build.gradle) is important. If I define the spring annotation processor first like this, it doesn't work, I get no properties at all. 

annotationProcessor("org.springframework.boot:spring-boot-configuration-processor") annotationProcessor("org.projectlombok:lombok:1.18.16")

but if I switch the order like this, everything works fine

annotationProcessor("org.projectlombok:lombok:1.18.16")
annotationProcessor("org.springframework.boot:spring-boot-configuration-processor")