Has anybody else tried Lombok?

[Matt]

My coworker and I tried it a few weeks ago and got nothing. We both
got it to install but when we added the annotations and the import
statements, nothing happened. Eclipse obviously saw the jar file since
it would auto-add the import like it should have, but then nothing
happened. I posted in their forum but I only got basically "It should
have worked" in response. We'd love to use it but since it did nothing
for either of us we were a little disheartened. If it was just me that
would be one thing but neither of us got anything.

Are we alone in having it not work for us?

[Casper Bang]

Sure, works fine here on 64bit Ubuntu 9.04 and Eclipse 3.5. Did you
remember to install the extension to Eclipse (run lombok.jar as a Java
application and point to your eclipse installation folder)? The
checkedException prototype does not work for me however.

/Casper

[Matt]

Yeah, we installed it to our Eclipses. That's what's weird, it seems
like it works fine for everybody but both of us.

[Reinier Zwitserloot]

Hey Matt,

I really don't know what to say. There's not much to go on when all I
get is "it doesn't work for us". Are there errors in the error view?
Did you try downloading a fresh new eclipse? Give me _something_ to
work with.

[Matt]

I don't have much to go on either, it just does nothing. I get the
import statement and add the annotation, then nothing. I haven't tried
it on a fresh Eclipse though. I'll try it on my home machine when I
get there.

[Ed G]

There's the Eclipse error log you can look at, when I'm having
problems with plugins sometimes exceptions show up there. You can get
to it by going to Help->About Eclipse (at the bottom) -> Configuration
Details -> View Error Log

[Steve]

I hope they soon add knowledge of Eclipse's field prefixes so the
@Data class annotation will generate getters/setters without the
prefix.

Right now

class @Data Car
private int fSpeed;

produces

setFSpeed(int)
getFSpeed()

On Aug 24, 4:10 pm, Matt <mattgrom...@gmail.com> wrote:

[Casper Bang]

Ah, the wonderful inconsistent world of Java pseudo "properties". So
for boolean types, will we generate isFoo() or getFoo() or both?

/Casper

[Reinier Zwitserloot]

isFoo() at the moment. If you want getFoo(), knock yourself out and
add it. @Data/@Getter is smart enough to not also generate isFoo() if
you already wrote getFoo(). With sufficient domain knowledge these
inconsistencies are quite managable.

NB: Steve, for those field prefixes, file an issue if there isn't one
already there to treat anything matching the pattern xFoo, where x is
a lowercase character and F is title or uppercase, to be named as
'foo' (where f is the lowercase form of F).

[Roel Spilker]

Hmm. Even if we add knowlegde about Eclipse field prefixes, it would
mean that the same file compiled by javac would result in a different
file. Maybe we can have a -D command line parameter for javac and use
the Eclipse setting implicitly.

Is there a reason you are so fond of the field prefix? After all,
since you are using Eclipse, there is this nice syntax coloring to
indicate the identifier refers to a field.

Roel

[Roel Spilker]

For fields of type boolean, Lombok will generate isFoo() unless a
method called getFoo() or hasFoo() exists :-)

On Aug 25, 5:58 pm, Casper Bang <casper.b...@gmail.com> wrote:

[Steve]

Thanks, Reinier, I submitted an issue.

As far as field prefixes, it's in our style guide and I've been doing
it forever, but I'm starting to question it. As Roel mentioned, IDEs
help you distinguish them. Our Groovy classes certainly don't have
prefixes. It's cleaner... Hmm...

So how many folks use field prefixes still?

Steve