Assistance with @SuperBuilder and Quarkus PanacheEntity Integration

[Renato Tomio]

Hello Lombok and Quarkus Communities,

I'm currently working on a Quarkus application that leverages Panache for ORM capabilities, specifically using PanacheEntity for domain entities. I've encountered an integration challenge when trying to apply Lombok's @SuperBuilder annotation to my entities which extend PanacheEntity.

The core of the issue seems to stem from the @SuperBuilder annotation's requirements for inheritance, where it expects all superclasses to be annotated with @SuperBuilder to generate a coherent builder pattern. Given that PanacheEntity and PanacheEntityBase are part of an external library and cannot be modified to include these annotations, this has put me in a bit of a bind.

My goal is to leverage both the active record pattern provided by Panache and the convenient builder pattern generated by Lombok's @SuperBuilder. However, the direct application of @SuperBuilder to entities extending PanacheEntity results in compilation errors, specifically around unresolved symbols which seem to be related to the generated builder classes not correctly extending or incorporating the base Panache functionality.

To work around this, I've considered various approaches, including creating an adapter or wrapper class that would allow me to use @SuperBuilder without directly extending PanacheEntity, but this introduces additional complexity and somewhat defeats the simplicity that Panache brings to the table.

I'm reaching out to both communities to see if there are any known solutions, workarounds, or if there's potential for feature adjustments in future versions that might better accommodate this use case. Perhaps there's an aspect of the integration that I'm overlooking, or maybe others have devised creative solutions to similar challenges.

Any guidance, suggestions, or shared experiences with integrating Lombok's @SuperBuilder and Quarkus PanacheEntities would be greatly appreciated. I'm also interested to hear if there are plans to enhance compatibility between these two powerful libraries in future updates.

Thank you in advance for your time and assistance.

[Jan Rieke]

Hi  Renato,

I don't have any experience with Panache, but it seems that lombok's @SuperBuilder may not be the best choice for that case. From what I understand by reading the Panache examples on the Quarkus website, PanacheEntitys typically have public data fields and/or public setters, i.e. they are not (and should not be) immutable. I don't see a real advantage in using a builder-pattern here, because it does not improve readability in comparison to using those fields/setters directly.

Furthermore, improving lombok to support cases where superclasses do not have the @SuperBuilder is extremely complicated, because it requires resolution. Thus, I don't think there is a reasonable way how lombok could support your use case.

To work around this, I've considered various approaches, including creating an adapter or wrapper class that would allow me to use @SuperBuilder without directly extending PanacheEntity, but this introduces additional complexity and somewhat defeats the simplicity that Panache brings to the table.

If you really want @SuperBuilder for your entities, you could use a "superbuilder enabler" helper class; see this StackOverflow answer for an example how to do this. I don't think that this adds much complexity, because there is only the id field in PanacheEntity that you need to consider, and you can reuse this helper class for all your entity classes.

Best regards

Jan