Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate configuration keys metadata for immutable POJOs #16071

snicoll opened this issue Mar 2, 2019 · 2 comments


None yet
2 participants
Copy link

commented Mar 2, 2019

Follow up of #8762

We need to generate proper metadata for the immutable style as the rules are different. We currently check for the presence of a setter to determine what needs to be exposed. In the immutable case, constructor arguments will be used for this.

@snicoll snicoll added this to the 2.2.x milestone Mar 2, 2019

@snicoll snicoll self-assigned this Mar 2, 2019

snicoll added a commit to snicoll/spring-boot that referenced this issue Mar 4, 2019


This comment has been minimized.

Copy link
Member Author

commented Mar 4, 2019

Interesting to look at this from a metadata angle. I was wondering how we could infer default values. In a getter/setter arrangement, if you define a value with a primitive type, it gets its default value unless specified otherwise (i.e. a boolean flag is false by default).

With the constructor arrangement, it gets a tad more complex. If we ignore validation (@NotNull) we could probably infer false as well if the constructor parameter uses the primitive type. There is a test failing in the branch that illustrates that scenario.

@snicoll snicoll modified the milestones: 2.2.x, 2.2.0.M2 Mar 22, 2019

@snicoll snicoll closed this in 3125f42 Mar 22, 2019


This comment has been minimized.

Copy link
Member Author

commented Mar 22, 2019

The metadata on the Java side has been improved to detect immutable types. When a @DefaultVaue is set, we try to coerce for primitive types and generate a better representation of it in the metadata.

Kotlin types are not supported as kapt still exposes several limitations. I've created #16293 to follow-up and try to improve this as much as we can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.