👤 de4726   🕗 Aug 08, 2014 at 16:30 UTC

What steps will reproduce the problem?

1. Create a class with attributes like

   @ Getter @ Setter
   private String eMail;

   @ Getter @ Setter
   private int aValue;

or something like this and use Lombok's @ Getter and/or @ Setter annotations (either on class or attributes, no difference).

Important: Start attribute name with a lower case letter, followed by an uppercase one!

1. The getters and setters created by Lombok will have the following names:

   setEMail(.) / getEMail(), setAValue(.) / getAValue().

These names are wrong!

In fact, they are neither getters nor setters, and when used in contexts which rely on existing getters and setters and adhere to the Java Bean spec, such classes won't work properly.

What is the expected output? What do you see instead?

According to the Java Bean specification, the getter for

  private int aValue;

must be "getaValue()" -- NOT "getAValue()

Setters accordingly, of course.

(Yes! With a lower case 'a'! -- This is a special case when the first letter is lower case and the second upper case.)

If getters/setters will be created with Eclipse ("Source -> Generate Getters and Setters..."), they would be correct. I assume this is the case with any recent IDEs.

What version of the product are you using? On what operating system?

Tried Eclipse on Win7 and Linux, using Lombok 1.12.6 and 1.14.4.

All the same.

Please provide any additional information below.

👤 reinierz   🕗 Aug 14, 2014 at 00:59 UTC

See also https://groups.google.com/forum/﹟!topic/project-lombok/c9WKYhlfe8k for discussion on this.

Technically a breaking change but I'm game. Between this request and the newsgroup thread, plenty of supporting evidence that getaValue() is far more likely to be 'the right thing'.

👤 lennyprimak   🕗 Aug 14, 2014 at 14:14 UTC

This should be configurable. We have plenty of code that depends on this bug.
However, I fully support this change because it's the right thing to do.
Thanks

👤 reinierz   🕗 Aug 15, 2014 at 22:15 UTC

After further review (see newsgroups thread linked in comment 1), the java community is split down the middle on this. No matter what we do, we'll be incompatible with about half of the things out there, so we might as well stick with the half we already support right now*.

*) The half we support right now looks to be a bit less than 50% actually, but it's at this point not worth the hassle to change things.

End of migration

as I think, the eclipse and IDEA do the right things, why are not you in conformity with them???

Maybe, we should create @xGetter and @xSetter annotations with new behavior?

@o-pikozh No, clearly a world where there are 18 different @FooGetter annotations, each with slightly different behaviour, is far worse than what we have now. In 99.99% of all cases this doesn't matter, but having multiple getter annotations is something lots of people are going to see and then they need to have their day rudely interrupted to read all about exotic, irrelevant details.

It is what it is.

Please make it happen without breaking change, @Getter(strict=true), @Setter(strict=true) could do the job.

It breaks many use case relying on javabeans specifications (serialization librairies, frameworks, ...)

Duplicate of #2693

Simple things have to be complicated，it's so low!

@Ketty0725 If you read the linked catch-all issue, you can see that it is not as simple as it looks at first glance. And this is fixed, by the way.