generate hasFOO() for boolean fields named 'hasFOO' instead of 'isHasFOO' about lombok

[bmmpt]

Why not give the developer the ability so set the exact getter/setter name they what to use?

For instance I have a Boolean getter I would like to call canAdd... rather than isAdd or hadAdd.

Something like the following would be nice:

@getter(name="canAdd")
@Setter(name="setCanAdd")
private Boolean thisNameDoesNotMatter;

[Ghedeon]

Sorry, I see that it's an old thread, but do I miss something or was it reverted? Because it generates isHasFoo() for the field named hasFoo in v1.16.16.

[lombokissues]

👤 reinierz   🕗 Jul 24, 2009 at 04:17 UTC

What steps will reproduce the problem?

1. Create a class with a field named 'hasX', typed 'boolean'.
2. Put a @ Data annotation on it.
3. Get annoyed by the 'isHasX()' name. 'hasX()' is most likely far more appropriate.

Fix: If boolean field and the field name starts with 'has', use the field name as method name.

[lombokissues]

👤 r.spilker   🕗 Jul 24, 2009 at 11:04 UTC

Also, we might want to check if any of the is/has/get methods exists befor creating
one.

[lombokissues]

👤 r.spilker   🕗 Jul 25, 2009 at 21:10 UTC

If the field starts with "is" we don't want to prepend another "is". We need to make
sure that "is" or "has" is not the start of a longer word. So the next character has to
be title case. This ensures that a boolean field called hashCodeCalculated would get a
getter named isHashCodeCalculated instead of hasHCodeCalculated.

[lombokissues]

👤 reinierz   🕗 Jul 26, 2009 at 07:19 UTC

Implemented all suggested changes in commit a9d2989.

NB: Roel, I haven't tested all borderline cases on this one!

[lombokissues]

👤 reinierz   🕗 Jul 26, 2009 at 07:30 UTC

Test ﹟1: Make boolean fields named 'isFoo', 'getBar', 'hasBaz' and 'hashFlooble'. This must generate methods
'isFoo(), hasBaz, getBar, and isHashFlooble.

On eclipse: Correct on all counts.

On javac: Correct on all counts.

Test ﹟2: Make boolean fields named 'isFoo', 'bar'. Then make methods named 'hasFoo', and 'getBar', and make
sure that neither field gets an auto-generated getter, and that both fields get a warning that no getter is
being made, with the alternate name stated in the warning message.

on eclipse: correct on all counts.

on javac: correct on all counts.

Thus, I'm verifying the change.

[lombokissues]

End of migration

[Maaartinus]

@Ghedeon IIRC this has indeed been reverted. It makes the names sound better, but it's another "prefix-shedding", incompatible with javabeans and not very systematic. There (at least) following possibilities:

• javabeans compatible
• no prefix
• always get/set (never "is")