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

Wrong getter/setter names for generated for certain corner cases #1129

Closed
janzyka opened this issue Jun 13, 2016 · 7 comments
Closed

Wrong getter/setter names for generated for certain corner cases #1129

janzyka opened this issue Jun 13, 2016 · 7 comments

Comments

@janzyka
Copy link

janzyka commented Jun 13, 2016

Lombok generates non-valid getter names for certain corner cases of Java Bean specification.

Namely fields which have second letter uppercase like xAxis or iMessage should become setxAxis(...) and setiMessage(...) - not very intuitive but it seems to be that way. Lombok on the other hand generates setXAxis(...) and setIMessage(...).

This issue usually doesn't do much harm until you do something like deserialize object annotated via @Data through Jackson. In this case those fields remain unset because no setter with valid name exists for such fields.

There is a blog post explaining this issue nicely.

@nick-yegw
Copy link

Yes, I met the same issue when using fasterxml.jackson to generate xml from javabean, which has used the "@DaTa"

And you can find the related doc from oracle about this:
http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/

Please refer to below section:
8.3.1 Simple properties
8.3.2 Boolean properties
8.8 Capitalization of inferred names.

Thus when we extract a property or event name from the middle of an existing Java name, we
normally convert the first character to lower case. However to support the occasional use of all
upper-case names, we check if the first two characters of the name are both upper case and if
so leave it alone. So for example,
“FooBah” becomes “fooBah”
“Z” becomes “z”
“URL” becomes “URL”
We provide a method Introspector.decapitalize which implements this conversion rule.

I think it would be better to fix this bug asap, otherwise, some magic bug would be hard to found.

@askoning
Copy link
Collaborator

See #504 , #757 for older discussions on this.

@anddero
Copy link

anddero commented Sep 1, 2020

In #757 this was dropped due to Java community being split on the topic. I still believe it is worth the hassle and could be fixed in the next major release.

A better option might be to include a new strict parameter for the @Getter, @Setter and @Data annotations to allow this functionality without any breaking changes (as suggested here), for as long as it is not the default behavior.

The current workaround is to write your own getters and setters for fields related to this issue, to conform to the JavaBeans API Specification.

@randakar
Copy link

randakar commented Sep 1, 2020

There is a simpler workaround for Jackson: The new '@Jacksonize' annotation that is in the edge release, possibly with '@JsonProperty' / '@JsonGetter' on any fields still having issues.

As for the whole bean naming issue: The whole point of it is that there is no single spec everyone adheres to. There is no such thing as 'strict' when doing that breaks half of the world.

@Rawi01
Copy link
Collaborator

Rawi01 commented Sep 1, 2020

@anddero You can also add @Setter(AccessLevel.NONE) @Getter(AccessLevel.NONE) to the field you want to exclude, that might be easier if there are only one or two fields.

One of the maintainers already mentioned that they will accept a PR that changes this (unfortunately only without a config key to get back the current behaviour...).

@anddero
Copy link

anddero commented Sep 1, 2020

It seems, when you have a custom accessor like getxAxis(), Lombok detects this and does not generate an additional getXAxis(). This makes the workarounds much simpler.

@Rawi01 So it is not even necessary to add those annotations to specific fields.

@rzwitserloot
Copy link
Collaborator

Duplicate of #2693

@rzwitserloot rzwitserloot marked this as a duplicate of #2693 Jan 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants