👤 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