Eclipse Issues with Lombok Extension
phancox
build extensions that are integrated into our standard development
environment.
Started with a base install of Lombok 0.9.2 Everything went fine
except that when working with @Getter @Setter etc. I found that
"import lombok.*;" doesn't work (at least under Eclipse it didn't).
It was necessary to individually import each annotation (i.e., "import
lombok.Getter; import lombok.Setter;").
I then tried developing a simple custom @Logger annotation using the
Morbok project as an example. That all went fine until I tried moving
the HandleLogger implementation classes from the "lombok" name space
to my own name space. After the refactoring, the extension still
worked when using javac but it didn't seem that eclipse (3.5.1) could
find the extension. I noticed some discussion on the mailing list
about this being a restriction but I thought that it wasn't supposed
to be an issue with later versions of lombok?
After moving the handlers back into the lombok name space I noticed
another issue. My extension simply creates the standard Logger
instance as a private static field. Works fine with javac but eclipse
doesn't like it when the field defined by the lombok extension is
referenced in a static initialiser. Complains with "Cannot reference
a field before it is defined". Still compiles OK with javac.
Quite excited by this project. Many years ago we used to use C/C++
macros to eliminate a lot of boiler plate code and ensure consistent
implementation across developers. Lombok should allow us to do much
the same but with considerably more functionality.
Unfortunately, the learning curve looks like being pretty steep so
would appreciate any assistance on what is "normal/expected"
behaviour. Any tips on debugging this stuff? How to check whether
the extension code is actually being called in eclipse? Can eclipse
debugger be used?
Currently have eclipse boot class path pointing to the class path
directory for the infrastructure project so changes made to the
extension code are immediately available, however, have to restart
eclipse to pick up the changed code. This is not unexpected but is
there any way to get eclipse to reload the changed code without a
restart?
REGARDS
Peter
Reinier Zwitserloot
On Feb 12, 1:33 am, phancox <phan...@dtc.com.au> wrote:
> Started with a base install of Lombok 0.9.2 Everything went fine
> except that when working with @Getter @Setter etc. I found that
> "import lombok.*;" doesn't work (at least under Eclipse it didn't).
> It was necessary to individually import each annotation (i.e., "import
> lombok.Getter; import lombok.Setter;").
That's not supposed to happen but not surprising either. We don't have
resolution (yet) so lombok has to guess whether "@Getter" means
"lombok.Getter" or some other getter, and without a full classpath to
rely on that's hard to do when star imports are used. Nevertheless, in
normal circumstances (there's no other @Getter that you also star-
import), lombok _should_ work with star imports. So, bug report
http://code.google.com/p/projectlombok/issues/detail?id=102 has been
filed so we don't forget to fix this.
>
> I then tried developing a simple custom @Logger annotation using the
> Morbok project as an example. That all went fine until I tried moving
> the HandleLogger implementation classes from the "lombok" name space
> to my own name space. After the refactoring, the extension still
> worked when using javac but it didn't seem that eclipse (3.5.1) could
> find the extension. I noticed some discussion on the mailing list
> about this being a restriction but I thought that it wasn't supposed
> to be an issue with later versions of lombok?
>
It isn't. Or rather, shouldn't be. As Roel and I are working on
changing quite a bit of lombok-core we may not fix this (as the new
core will most likely make any fixes obsolete, and we're just 2 folks
working on this in our spare time), so for now you may just have to
work around this issue by using the lombok namespace.
> After moving the handlers back into the lombok name space I noticed
> another issue. My extension simply creates the standard Logger
> instance as a private static field. Works fine with javac but eclipse
> doesn't like it when the field defined by the lombok extension is
> referenced in a static initialiser. Complains with "Cannot reference
> a field before it is defined". Still compiles OK with javac.
That's actually a correct error message; each static field declaration
is its own tiny static initializer, and the combination of all static
initialization code is like one single method. You can't do this:
System.out.println(x);
int x = 10;
either, and the same thing is happening for you. The only bug here is
that lombok-javac (or morbok, not sure who is doing the actual
inserting) adds things to the beginning, whereas lombok-eclipse adds
it to the end. In other words, in javac, you end up with this:
class Example {
private static final Logger logger = ...; //generated by lombok
here.
static {
logger.foo();
}
}
whereas in eclipse you end up with:
class Example {
static {
logger.foo();
}
private static final Logger logger = ...; //generated by lombok
here.
}
You can use the eclipse debugger; "ant installDeps" does many things,
among which is add an eclipse run target that starts a _new_ eclipse
from inside eclipse that is lombokized. Unfortunately the lombok code
used in the spawned eclipse is the jar and not the live code
(unavoidable - annotation processors and agents both _HAVE_ to be
jars), but breakpoints and the like do work. We've played around with
eclipse (even a debug-mode spawned eclipse) pick up changes 'live' but
due to the requirement that agents are jar files, we haven't been able
to make this work.
Peter Hancox
My reponses also inline.
On Feb 13, 4:17 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> replies inline.
>
> On Feb 12, 1:33 am, phancox <phan...@dtc.com.au> wrote:
>
> > Started with a base install of Lombok 0.9.2 Everything went fine
> > except that when working with @Getter @Setter etc. I found that
> > "import lombok.*;" doesn't work (at least under Eclipse it didn't).
> > It was necessary to individually import each annotation (i.e., "import
> > lombok.Getter; import lombok.Setter;").
>
> That's not supposed to happen but not surprising either. We don't have
> resolution (yet) so lombok has to guess whether "@Getter" means
> "lombok.Getter" or some other getter, and without a full classpath to
> rely on that's hard to do when star imports are used. Nevertheless, in
> normal circumstances (there's no other @Getter that you also star-
> import), lombok _should_ work with star imports. So, bug reporthttp://code.google.com/p/projectlombok/issues/detail?id=102has been
> filed so we don't forget to fix this.
>
>
Thank you. No great problem to work without the star import just have
to watch when performing Eclispe "Clean Up..."
The project I'm using the annotations in has many libraries in the
build class path. I'm not aware of any other ".....Getter"
annotations but wouldn't surprise me either.
>
> > I then tried developing a simple custom @Logger annotation using the
> > Morbok project as an example. That all went fine until I tried moving
> > the HandleLogger implementation classes from the "lombok" name space
> > to my own name space. After the refactoring, the extension still
> > worked when using javac but it didn't seem that eclipse (3.5.1) could
> > find the extension. I noticed some discussion on the mailing list
> > about this being a restriction but I thought that it wasn't supposed
> > to be an issue with later versions of lombok?
>
> It isn't. Or rather, shouldn't be. As Roel and I are working on
> changing quite a bit of lombok-core we may not fix this (as the new
> core will most likely make any fixes obsolete, and we're just 2 folks
> working on this in our spare time), so for now you may just have to
> work around this issue by using the lombok namespace.
>
Not really a problem particularly as intended use is internal only so
I can change the name space at any time.
Just nice to know what's normal/expected in case I've just stuffed
something up here.
Expected something like that. Fixing it should be a good exercise for
me to understand more of the internals as to how everything all comes
together.
Once again, thank you for your detailed response.
v6ak
Eclipse supports auto-completion by ctrl-space. It also solves all
imports. So, write (for example) "@Sett" and press ctrl+space ..
Peter Hancox
The main "gotcha" to watch out for is when running Eclipse "Code
Cleanup..." One of its configuration options will merge multiple
individual imports into their star equivalent; in this case
effectively breaking the Lombok annotations. You'd then see errors
for the @Getter and @Setter annotations.
No big deal as it doesn't really break the code and the "errors"
appear immediately. But difficult to find the cause unless you've
noticed it before.
Vít Šesták
import bar.*;
import baz.*;
...
new Foo() // bar.Foo
When you create baz.Foo, you break the source.
I think that Eclipse is deeply configurable so I recommend to not use
this option redardless it breaks any extension.
> --
> You received this message because you are subscribed to the Google
> Groups group for http://projectlombok.org/
>
> To post to this group, send email to project...@googlegroups.com
> To unsubscribe from this group, send email to
> project-lombo...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/project-lombok?hl=en