Do you still use quarkus (hibernate) with lombok?

[Paul6552]

I use Quarkus (Hibernate) with Panache as well as Lombok for getter, setter, tostring and equals methods.
I heard in discussions that Lombok should be replaced.

Panache also offers these functions and you could replace Lombok, you just have to set the access to public.

Example with Lombok:

@Entity
@Data
@NoArgsConstructor
@AllArgsConstructor
public class Person extends PanacheEntityBase implements Serializable {

@Id
@GeneratedValue( strategy = GenerationType.AUTO )
private Long id;

@Basic
@Column(name = "name", nullable = false)
private String name;
}

Another Class:
person.getName();

Without Lombok it would look like this:

@Entity
public class Person extends PanacheEntityBase implements Serializable {

@Id
@GeneratedValue( strategy = GenerationType.AUTO )
public Long id;

@Basic
@Column(name = "name", nullable = false)
public String name;
}

Another Class:
person.name;

Everything I always learned about programming "Encapsulation of objects" is thrown overboard. Is this the way Quarkus is going or should Quarkus continue to be used with Lombok?

Thanks

[quarkus-bot[bot]]

/cc @gsmet (hibernate-orm), @yrodiere (hibernate-orm)

[yrodiere]

Everything I always learned about programming "Encapsulation of objects" is thrown overboard.

If you want to do true object-oriented programming and encapsulation, then I'm afraid hiding field access behind getters and setters is not it.
If you wanted true encapsulation, you would not have getters and setters, but you'd have meaningful, business-related methods, e.g. person.marry(otherPerson), person.giveBirth(otherParent, firstName), etc. Which I hope you're starting to see is not exactly practical.
With getters and setters, your fields are not encapsulated, they're just accessible through an additional -- arguably annoying -- layer of ceremony. You can still get and set their value any way you want. Most people won't even add validation to the setters, simply because it's not practical: you generally want to validate user input all at once, and report all constraint violations, not just the one that was detected and thrown as an exception by the first setter call.

Most likely the only valid reason we've ever used getters and setters on JPA entities is not encapsulation, it's lazy loading and dirty tracking. To handle those, Hibernate ORM needs to be able to intercept read or write access to fields, and trigger inititalization (for lazy loading) or register modification (for dirty tracking). Field access in Java cannot (easily) be intercepted through proxying / bytecode manipulation; getter/setter calls can be.

But, Quarkus has this peculiarity that, in order to target GraalVM, it builds applications in a closed world: it is aware of the whole code that will ever be executed, and does not accept that new JARs get introduced after the build -- because that's rarely useful anyway, and preventing it allows optimizations.
That closed-world guarantee means that it becomes realistic (and, critically, safe) to allow entities to have public fields, and the application to use field access: upon building the application, Quarkus will just go through the whole bytecode, and replace those field accesses with calls to bytecode-generated getters and setters. The getters and setters are still there, you just don't see them, and don't have to deal with them.

Note that "field access replacement" feature is also available in the "vanilla" Hibernate ORM bytecode enhancer, under the questionable name of "extended bytecode enhancement", but is dodgy in applications that don't have a "closed-world" guarantee, so more rarely used.

Also note that you don't need Panache to benefit from this "field access replacement", it's performed in Quarkus even if you're just using Hibernate ORM without Panache.

Is this the way Quarkus is going or should Quarkus continue to be used with Lombok?

I would personally only use Lombok if I need a feature in there that is not already addressed by Quarkus.

Getter/setter generation, is, IMO, largely irrelevant for Hibernate ORM entities, as Quarkus does it already (but in a more discreet, behind-the-curtains way). It could be useful for non-entity classes, for example DTOs, if you want getters/setters there. But even then, for DTOs immutability is an option, and Java records are generally a better alternative to immutable classes with getters.
(And before someone asks, no, records are not an option for entities, because records are immutable, which prevents lazy loading and more generally just doesn't match the identity-tied concepts of JPA)

equals/hashcode generation for entities is complex, so I doubt Lombok is appropriate in that case, but it could work for non-entity classes.

Constructor and builder generation is more appealing, so if you need those, then sure, Lombok makes sense.

I'm sure Lombok has many more features that can also make sense in Quarkus.