Lombok: Builder do not recognize abstract class fields

Created on 10 Dec 2015  路  11Comments  路  Source: projectlombok/lombok

examples.

public abstract class IGameActor {
public int id;
}

@Builder
public class Npc extends IGameActor {
}

Npc.builder.id(0).built();

That doesn't work

Most helpful comment

Pointing to the parent class doesn't help. We still would need resolution to look up the class, and find out what its fields are.

Sometimes, the parent class is in a jar. Sometimes it is a Java class, that nowadays is in some undocumented binary format. The class could also be in a class file on disk. In a separate source file. In the same source file.

We cannot create resolution. We need to use ecj or Java for that.

But they also cannot always answer those questions because they are still figuring it out themselves. They are busy parsing files, trying to make sense of it all.

So far, we haven't found a way to make this work.

If someone can show us how to do resolution in a reliable way that doesn't allow down the compilation process by a huge factor we would be very happy!

All 11 comments

Is the project dead ? if not i can try to push something

Is the project dead ?

For sure not.

if not i can try to push something

You probably can't. The problem is not the abstract class, but the inheritance. Lombok has currently no sane way to access superclasses, so such things just can't work (though they'd be very useful; I'm missing especially calling superclass constructors). The authors are well aware of the problem, but know no good solution.

And it is the same for the annotation @ToString , you can't see parameters for the class parent

What if you add an option to the annotation @Builder(parent = IGamActor.class)

Is there any reason there is no progress for this? @ToString and @EqualsAndHashCode have a callSuper argument. Would be perfect if @Builder would also get that.

also for the AllArgsConstructor

The reason there's no progress on this, is because it is not really possible for lombok to inspect the contents of your parent class without making lombok about 10x more complex than it is, and slowing your build waaaay down.

One day, one fine day, we will find a way to do resolution right, and then we'll fix about 800 of these 'bugs' (we've documented this behaviour so they aren't bugs, but I get that it's somewhat surprising and that's a bit of a copout).

Until then, we just close these, unfortunately.

How taking care of a param pointing to the parent class @Builder(parent = IGamActor.class)
would be slowing down the compilation ?
@rzwitserloot
Please do at least some bench or let us push code modification.

@SharpMan

Disclaimer: A Lombok fan here.

How taking care of a param pointing to the parent class @Builder(parent = IGamActor.class)

You need no param as it's in public class Npc extends IGameActor already.

would be slowing down the compilation?

See Resolution. I don't really understand it myself, but I'm sure it's complicated.

Please do at least some bench or let us push code modification.

Cloning the repository on GitHub takes about one second and the copy is only yours. If you could solve it, it'd be fantastic, but be assured that others tried and failed.

Pointing to the parent class doesn't help. We still would need resolution to look up the class, and find out what its fields are.

Sometimes, the parent class is in a jar. Sometimes it is a Java class, that nowadays is in some undocumented binary format. The class could also be in a class file on disk. In a separate source file. In the same source file.

We cannot create resolution. We need to use ecj or Java for that.

But they also cannot always answer those questions because they are still figuring it out themselves. They are busy parsing files, trying to make sense of it all.

So far, we haven't found a way to make this work.

If someone can show us how to do resolution in a reliable way that doesn't allow down the compilation process by a huge factor we would be very happy!

Hmm, maybe I miss a point here, but properties from abstract superclasses are also supported by @SuperBuilder. Why not use that?
The superclass(es) need the annotation too, but that seems to be possible in this case.

Was this page helpful?
0 / 5 - 0 ratings