Lombok is a popular framework among Java developers because it generates repetitive boilerplate code like getter and setter methods, equals and hashCode methods, and the default constructor. All you need to do is add a few annotations to your class and Lombok will add the required code at compile time. This works reasonably well for normal classes, but it introduces a few dangerous pitfalls if you use it for your Hibernate entities.

To avoid these pitfalls, I recommend NOT using Lombok for your entity classes. If you use the code generator features of your IDE, it will take you less than a minute to create a much better implementation of these methods yourself.

So, let’s take a look at some of Lombok’s most popular annotations and why you need to be careful when using them with Hibernate.

A Basic Domain Model

In all of the following examples, I will use this very basic domain model. The Order entity class represents the order in an online store.

For each Order, I want to store the ID, the name of the customer, and one or more order positions. These are modeled by the OrderPosition class. It maps the ID, the name of the product, the ordered quantity, and a reference to the Order.

3 Lombok Annotations You Need to Avoid

Lombok is an incredibly popular framework despite having few annotations. This is because it addresses developer pain points.

However, Lombok doesn’t work well with many other frameworks. I recommend you avoid three of its most commonly used annotations.

Don’t Use @EqualsAndHashCode

The necessity of implementing the equals() and hashCode() methods for entity classes is often discussed amongst developers. This seems like a complicated and important topic because of the need to fulfill both the contracts defined by the Java language specifications and rules defined by the JPA specification.

But, it’s actually a lot simpler than it might seem. As I explained in great detail in my guide to implementing equals() and hashCode(), your hashCode() method should always return a fixed value, for example 42. In the equals() method, you should only compare the type of the objects and their primary key values. If at least one of the primary keys is null, the equals method has to return false.

If you don’t want to implement these methods yourself, you can annotate your class with Lombok’s @EqualsAndHashCode annotation.

Lombok then generates the following equals() and a hashCode() methods.

If you take a closer look at both methods, you can see that they don’t follow my previous recommendations. This causes multiple issues.

Let’s start with the most obvious one: both methods include all non-final attributes of the class. You can change that by setting the onlyExplicitlyIncluded attribute of the @EqualsAndHashCode annotation to true and annotating the primary key attribute with @EqualsAndHashCode.Include.

Lombok then only includes the primary key value in the hash code calculation and equals check.

That will not fix all issues. Your equals() method should return false if the primary key value of both entity objects is null. But Lombok’s equals() method returns true. Because of that, you can’t add two new entity objects to a Set. In the example shown above, that means that you can’t add two new OrderPosition objects to an Order. You should, therefore, avoid Lombok’s @EqualsAndHashCode annotation.

Be Careful with @ToString

If you annotate your entity class with Lombok’s @ToString annotation, Lombok generates a toString() method.

The returned String contains all non-final attributes of that class.

Using that annotation with an entity class is risky because it’s possible that not all attributes are being initialized. If you set the FetchType of an association to LAZY or use the default fetching of a many-to-many association, Hibernate will try to read the association from the database. If you’re doing this within an active Hibernate Session, this will cause an additional query and slow down your application. Worse yet is if you do it without an active Hibernate Session. In that case, Hibernate throws a LazyInitializationException.

You can avoid that by excluding all lazily fetched associations from your toString() method. To do that, you need to annotate these attributes with @ToString.Exclude.

As you can see in the code snippet, Lombok’s toString() method no longer includes the orderPosition attribute and avoids all lazy loading issues.

But for most entities, this approach:

• Adds several @ToString.Exclude annotations to your class, which makes it harder to read;
• Introduces the risk that every new lazily fetched association might break your application; and
• Requires more effort than using your IDE to generate the toString() method.

Avoid @Data

Lombok’s @Data annotation acts as a shortcut for @ToString, @EqualsAndHashCode, and @RequiredArgsConstructor annotations on your class; @Getter annotations on all fields; and @Setter annotations on all non-final fields.

So, if you build the Order class in the previous code snippet, Lombok generates getter and setter methods for all attributes and the methods equals(), hashCode(), and toString().

As I explained earlier in this article, Lombok’s equals() method isn’t suitable for entity classes and you need to be careful when using the @ToString annotation. Because of this, you shouldn’t use Lombok’s @Data annotation on your entity classes. On the other hand, you could use it for your DTO classes.

Conclusion

Entity classes have different requirements than plain Java classes. That makes Lombok’s generated equals() and hashCode() methods unusable and its toString() method risky to use.

You could, of course, use other Lombok annotations, like @Getter, @Setter, @Builder. I don’t think that these annotations provide a lot of value on an entity class. Your IDE can easily generate getter and setter methods for your attributes, and a good implementation of the builder pattern requires too much domain knowledge.

The bottom line is that you can use the @Getter, @Setter, and @Builder annotation without breaking your application. The only Lombok annotations you need to avoid are @Data, @ToString, and @EqualsAndHashCode.