Issues in eclipse

[James]

I'm having some odd behavior with Lombok. I created a test class just
to see how well it worked, and had no trouble.

import lombok.Data;

public @Data class TestLombok
{
private String name;
private double latitude, longitude;
private String country;

public void testMethod()
{
getName().toString();
}

public void testMethod(TestLombok other)
{
if (other.getName() == getName())
{
}
}
}

this worked great. So, I went and added this to my own (existing)
class and removed my getters/setters/equals/hashcode/tostring/etc...

import lombok.Data;

public @Data class PluginVersion
{
private Integer major;
private Integer minor;
private Integer release;

public PluginVersion(Integer major, Integer minor, Integer
release)
{
if (null == major || 0 > major)
{
throw new IllegalArgumentException("major cannot be null
or < 0.");
}

if (null == minor || 0 > minor)
{
throw new IllegalArgumentException("minor cannot be null
or < 0.");
}

if (null == release || 0 > release)
{
throw new IllegalArgumentException("release cannot be null
or < 0.");
}

this.major = major;
this.minor = minor;
this.release = release;
}

public int compareTo(PluginVersion object)
{
if (null == object)
{
throw new IllegalArgumentException("object cannot be
null.");
}

// Exact match
if (object.major == major && object.minor == minor &&
object.release == release)
{
return 0;
}

// Less than?
if (object.major <= major)
{
if (object.major == major)
{
// major versions match, check minor.
if (object.major <= minor)
{
if (object.minor == minor)
{
// minor versions match, check release.
// this won't be equal because it would be
caught above.
if (object.release < release)
{
return -1;
}
else
{
return 1;
}
}
else
{
// minor version is less than.
return -1;
}
}
else
{
// minor version is newer
return 1;
}
}
else
{
// major version is less than.
return -1;
}
}
else
{
return 1;
}
}
}


Now, after saving it and rebuilding, all of the classes that imported
that class now tell me:
The import PluginVersion cannot be resolved.

But, eclipse compiles the class and gives no errors. I have made sure
that lombok is in my projects build path as well.

Also, something interesting... in the compareTo method, if I used
object.getMinor(), object.getMajor(), object.getRelease(), it failed
to find those mehtods (it would give a compile error not being able to
find those methods, but they show up in the outline view).


Anybody have any thoughts on why this is happening?

[Reinier Zwitserloot]

I copied your code into my eclipse, and it works for me. Calling
getMajor() works, and the code is visible from other places. Possibly
your eclipse project isn't being built because of library path errors
- check the problems view.

[James]

Ok, something is a little odd here. Here is the setup that I've got:
Eclipse 3.5 on Linux x86_64.
I've got a maven2 project setup with projectlombok added as a
dependency (I've also added it directly to the project build path as a
user library)
I've fixed all of the issues that show up in the problems view and now
I have three errors in the test class that I built.
I've also run a clean & rebuild on the workspace.

All of the methods show up in the outline view and show up in the
available methods in the hint while typing.
However, they show up as compile-time errors in the code.

If I take the @Data attribute off of the class and add the getter/
setter, the project builds successfully.

[James]

Another note. If I use the command line maven tools, it builds just
fine.
So, this appears to be an eclipse issue.

I've tried to force eclipse to target java 1.6 and forced a full
rebuild (several times) and it still doesn't seem to be working.

Any other thoughts?

[James]

Ok, I think I figured something out here.

I created a fresh new project and added a couple test classes.
I enabled spring and it still worked fine.

It was when I tried to enable spring's aspects tooling that it starts
to fail.

After going back to my original project and using the Aspect Tools ->
Remove AspectJ nature, it all works correctly now.

So, it looks like there is a conflict with the lombok & aspect tools
in eclipse.

[Reinier Zwitserloot]

That's good to know. Could you file a ticket?

[James]

Done, ID 23.

[Steve]

I also got the "cannot resolve" issue in Galileo. Tried pulling out
Groovy and PyDev plugins but still had the problem. Ganymede was
fine, but I need something more universal, so my quick try of lombok
failed :(

On Aug 7, 4:45 am, James <warchild...@gmail.com> wrote:
> Done, ID 23.
>
> On Aug 6, 10:43 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>
>
> > That's good to know. Could you file a ticket?
>
> > On Aug 7, 3:45 am, James <warchild...@gmail.com> wrote:
>
> > > Ok, I think I figured something out here.
>
> > > I created a fresh new project and added a couple test classes.
> > > I enabled spring and it still worked fine.
>
> > > It was when I tried to enable spring's aspects tooling that it starts
> > > to fail.
>
> > > After going back to my original project and using the Aspect Tools ->
> > > Remove AspectJ nature, it all works correctly now.
>
> > > So, it looks like there is a conflict with the lombok & aspect tools
> > > ineclipse.
>
> > > On Aug 6, 4:01 pm, James <warchild...@gmail.com> wrote:
>
> > > > Another note.  If I use the command line maven tools, it builds just
> > > > fine.
> > > > So, this appears to be aneclipseissue.
>

> > > > I've tried to forceeclipseto target java 1.6 and forced a full

> > > > rebuild (several times) and it still doesn't seem to be working.
>
> > > > Any other thoughts?
>
> > > > On Aug 6, 3:51 pm, James <warchild...@gmail.com> wrote:
>
> > > > > Ok, something is a little odd here.  Here is the setup that I've got:

> > > > >Eclipse3.5 on Linux x86_64.

> > > > > I've got a maven2 project setup with projectlombok added as a
> > > > > dependency (I've also added it directly to the project build path as a
> > > > > user library)
> > > > > I've fixed all of the issues that show up in the problems view and now
> > > > > I have three errors in the test class that I built.
> > > > > I've also run a clean & rebuild on the workspace.
>
> > > > > All of the methods show up in the outline view and show up in the
> > > > > available methods in the hint while typing.
> > > > > However, they show up as compile-time errors in the code.
>
> > > > > If I take the @Data attribute off of the class and add the getter/
> > > > > setter, the project builds successfully.
>
> > > > > On Aug 5, 4:32 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
>

> > > > > > I copied your code into myeclipse, and it works for me. Calling

> > > > > > getMajor() works, and the code is visible from other places. Possibly

> > > > > > youreclipseproject isn't being built because of library path errors

> > > > > > > But,eclipsecompiles the class and gives no errors.  I have made sure

[Reinier Zwitserloot]

That's odd. Lombok was developed targetting galileo. It works in
ganymede, too, but that was sheer luck. What exact version are you
using?

[James]

It shows it cannot resolve them, but in my case I was able to ignore
those errors. They show up as errors, but didn't disrupt any tests or
the application from actually running.

[Steve]

Eclipse: Build id: 20090619-0625
Java: 1.6.0_11

Also, it's a pain that lombok doesn't know about field prefixes.

private int fMyInt

results in

setFMyInt()

no the desired

setMyInt()

[Reinier Zwitserloot]

You shouldn't be using field prefixes. That's what smart colouring
editors are for.

Complicating lombok's annotations with a prefix="f" or some such is
not worth the added complexity (not to mention how annoying it would
be to have to specify that everywhere!), so lombok would have to
guesstimate that that f is a field prefix. I guess a decent algorithm
would be:

if first letter is lowercase, and second letter is titlecase or
uppercase, and first letter is an english alphabet consonant, consider
it a field prefix.

However, it is more magic: It would be rather surprising in the rare
occasions when someone not using field prefixes so happens to have a
field named tFoo , and he was expecting to get a getTFoo(), not getFoo
().

[Reinier Zwitserloot]

Roel and I have discussed it, and we're not going to support them. We
have good reasons, and they are listed in the issue that we've just
set to WontFix for it:

http://code.google.com/p/projectlombok/issues/detail?id=39

> ...
>
> read more »

[Maaartin]

On Aug 20, 4:31 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> However, it is more magic: It would be rather surprising in the rare
> occasions when someone not using field prefixes so happens to have a
> field named tFoo , and he was expecting to get a getTFoo(), not getFoo
> ().

Sorry for my OT comment. I'm a complete newbie to lombok, but I must
say I agree fully with you. However, it looks like according to sun
such fields deserve no accessors at all. There's an interesting
"feature" concerning tFoo, which unfortunatelly gets used in
hibernate:

final String getterName = "getTFoo";
final String fieldName = Introspector.decapitalize
(getterName.substring(3));
System.out.println(fieldName);

So I had to rename my field "uShaped" to something else. I wonder if
it was possible to use a tool (lombok or something) to hack such
things lying completelly outside my code (sure I could replace
Introspector.class in rt.jar by myself, but this could have more
consequences than only more regular behaviour in hibernate; I could
replace all calls to decapitalize in hibernate.jar instead, but this
would be more work).

[Reinier Zwitserloot]

Yes, you can. Check out lombok.patcher at http://github.com/rzwitserloot/lombok.patcher
- it's a complete standalone from lombok itself (but lombok is
dependent on lombok.patcher), which you can use to relatively easily
'fix' code on-the-fly, directly at the runtime level. It's a bit
undocumented - really, checking out lombok as well and looking how
lombok's master branch uses it. (Lombok uses it to patch eclipse).