Lombok and the @Getter/@Setter capitalization rule

[Fabrizio Giudici]

I've downloaded Lombok for NetBeans - I'll start playing with it
tomorrow. Just a quick question. From the web pages I see:

"For generating the method names, the first character of the field, if
it is a lowercase character, is title-cased, otherwise, it is left
unmodified. Then, get/set/is is prefixed. "


I'd like to try to convert a bunch of JavaBeans of mine with vanilla
getters/setters with Lombok, but I see a problem with fields that are
acronyms. For instance, in my code a 'url' or 'exif' field are managed
by methods getURL() or getEXIF(), rather than getUrl() or getExif().
BTW, this is - I believe - the correct behaviour (see JavaBeans specs
v1.01, 8.8 Capitalization of inferred names. - I can't copy the
paragraph here since, ridiculously, the copy & paste drops all the
spaces). If you look at this javadoc there's an except of the important
part:

http://java.sun.com/javase/6/docs/api/java/beans/Introspector.html#decapitalize%28java.lang.String%29

****
Utility method to take a string and convert it to normal Java variable
name capitalization. This normally means converting the first character
from upper case to lower case, but in the (unusual) special case when
there is more than one character and both the first and second
characters are upper case, we leave it alone.

Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays as
"URL".
****

Now, Lombok is doing the opposite thing, as it converts a property name
to a setter/getter name, and must capitalize. I don't see it possible to
automatically understand where there's an acronym, so probably a
specific argument to the annotation can be given? Such as
@Getter(name="URL"), for instance.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Tor Norbye]

I think that capitalization approach has been out of favor for quite a
while. Here are my own thoughts on it (and I think I remember
changing my style to this after discussing coding style with Carl):

http://blogs.sun.com/tor/entry/code_advice_3_don_t

-- Tor

On Dec 3, 3:26 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> I've downloaded Lombok for NetBeans - I'll start playing with it
> tomorrow. Just a quick question. From the web pages I see:
>
> "For generating the method names, the first character of the field, if
> it is a lowercase character, is title-cased, otherwise, it is left
> unmodified. Then, get/set/is is prefixed. "
>
> I'd like to try to convert a bunch of JavaBeans of mine with vanilla
> getters/setters with Lombok, but I see a problem with fields that are
> acronyms. For instance, in my code a 'url' or 'exif' field are managed
> by methods getURL() or getEXIF(), rather than getUrl() or getExif().
> BTW, this is - I believe - the correct behaviour (see JavaBeans specs
> v1.01, 8.8 Capitalization of inferred names. - I can't copy the
> paragraph here since, ridiculously, the copy & paste drops all the
> spaces). If you look at this javadoc there's an except of the important
> part:
>

> http://java.sun.com/javase/6/docs/api/java/beans/Introspector.html#de...

>
> ****
> Utility method to take a string and convert it to normal Java variable
> name capitalization. This normally means converting the first character
> from upper case to lower case, but in the (unusual) special case when
> there is more than one character and both the first and second
> characters are upper case, we leave it alone.
>
> Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays as
> "URL".
> ****
>
> Now, Lombok is doing the opposite thing, as it converts a property name
> to a setter/getter name, and must capitalize. I don't see it possible to
> automatically understand where there's an acronym, so probably a
> specific argument to the annotation can be given? Such as
> @Getter(name="URL"), for instance.
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -www.tidalwave.it/people

> Fabrizio.Giud...@tidalwave.it

[Fabrizio Giudici]

WTor Norbye wrote:
> I think that capitalization approach has been out of favor for quite a
> while. Here are my own thoughts on it (and I think I remember
> changing my style to this after discussing coding style with Carl):
>
> http://blogs.sun.com/tor/entry/code_advice_3_don_t
>
>

Thanks Tor - I completely missed it. Most of my APIs are not finalized
yet, and for the other ones I'll discuss with people that are using
them; so I think I am still able to convert them.
What about updating the JavaBeans spec and add this note to it? :-)

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Reinier Zwitserloot]

I had a discussion with Roel about this during lombok development, and
I was adamant that I remembered places in the official java core
libraries (rt.jar) where something like getUrl() had been deprecated
in favour of getURL(). We bet a nice bottle of whiskey on it, and it
turns out nobody won; there are no cases (we could find) where one
capitalization has been deprecated in favour of another, but on the
other hand there is no official style guide (again, that we could
find) which states how to deal with this situation either. One of the
two had to be there for one of us to win the bet.

While I didn't have to shell out for the bottle, I was convinced that
acronyms should remain lowercased. Your own case (and Tor's blog)
explains why, really. It makes no sense to have:

private final URL url; //why are these cases mixed?

public void setURL(URL url) {this.url = url;} //What crazy mix of
casing is this?


The only two consistent forms are:

form A:

private final URL URL; //This looks funny but is legal.

public void setURL(URL URL) { this.URL = URL; }


and form B:

private final Url url;

public void setUrl(Url url) {this.url = url;}

Unfortunately, we can't rename classes in rt.jar, so A is the only
consistent form, but it looks really weird and I've never seen that
used in any code. Still, form A works fine in lombok, as lombok will
not titlecase your uppercase 'U' (titlecase is not the same thing as
uppercase mostly in languages like turkish). The style I now use, and
which Tor also suggests, is this B-based compromise:

private final URL url;
public void setUrl(URL url) {this.url = url;}

Which is also lombok-compatible. If there was an easy way for us to
change this rule, we would, but there's nothing that we can think of
that works. We can't store a database of acronyms, partly because
that's unwieldy, and partly because we would then force setURL on you,
whereas many folks prefer setUrl. We can't add a parameter to @Setter,
as that fails the 'common case' rule of lombok*, and we can't infer
your preference from anything that is guaranteed to be there. We could
perhaps infer casing from the variable's type name (URL), but then we
would again have to force setURL instead of setUrl on you. If we are
going to have to force choice, then setUrl() is both easier to explain
and seems to be the preferred standard.

The workaround is to write your own setURL() method, which, um...
crap. Would not prevent lombok from making setUrl as well, as lombok
is case sensitive in these things.

Huh. And I was on such a roll. Okay. New rule. Lombok won't make a
method if you've got the same method already, _regardless of casing_.
http://code.google.com/p/projectlombok/issues/detail?id=75

*) Lombok's common case rule states that any boilerplate busting
feature of lombok should cater only to the common case. For rare
corner cases, it is preferable to force people to just write what they
used to have to do (in this case, write the setter out manually), than
add a never ending procession of parameters onto the annotations and/
or let the smallprint on the feature pages grow into your average
legal document's size to cover all the corner cases. This keeps
grokking lombok's features simpler, and this trumps the minor gain of
helping out people in rare corner cases. Exception: If the corner case
is unlikely to register as such, and the resulting bug will likely go
undiscovered for quite a while. Particularly that last exception
clause (bug hard to find) does not apply here.


Thanks for raising this one, Fabrizio.

On Dec 4, 9:08 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

[Fabrizio Giudici]

Reinier Zwitserloot wrote:
> Thanks for raising this one, Fabrizio.
>
>

You're welcome. It helped make my code more consistent, also because I
always had that aesthetics issues with EXIFData, only that I preferred
to stick with a convention. Thanks to Tor, I got aligned. It will only
take more time for me to adopt Lombok, but it should be a matter of
weeks (there's nothing better than two weeks of XMas holidays to immerge
yourself in a massive code refactoring ;-)

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it