О том, как замечательно project lombok сам генерирует геттеры/сеттеры и конструкторы, я уже писал. Но у класса Object есть ещё методы и их тоже можно переопределять автоматически.

equals() и hashCode()

Эти методы глубоко пересечены, поэтому генерируются вдвоём, аннотацией @EqualsAndHashCode

/**
 * Sample user entity
 */
@FieldDefaults(level = AccessLevel.PRIVATE)
@AllArgsConstructor
@ToString
@EqualsAndHashCode(exclude = {"value"})
public class User {
    /**
     * Id.
     */
    @Getter
    Long id;

    /**
     * User name.
     */
    @Getter
    @NonNull
    String name;

    /**
     * Some entity, that you can't set.
     */
    @Getter
    @Setter
    @NonFinal
    BigDecimal value;
}

/**

* Sample user entity

@FieldDefaults(level = AccessLevel.PRIVATE)

@AllArgsConstructor

@ToString

@EqualsAndHashCode(exclude = {"value"})

public class User {

/**

* Id.

@Getter

Long id;

/**

* User name.

@Getter

@NonNull

String name;

/**

* Some entity, that you can't set.

@Getter

@Setter

@NonFinal

BigDecimal value;

}

Параметр exclude указывает, какие поля необходимо исключить из сгенерированных функций. По умолчанию так же исключаются все static и transient поля класса. Можно и наоборот, указать список полей, требующих включения, перечислив их в параметре of.

public class UserTest {
    @Test
    public void testEquals() {
        User testedObject = new User(1L, "TEST", BigDecimal.ONE);
        User oppositeObject = new User(1L, "TEST", BigDecimal.TEN);

        assertEquals(oppositeObject, testedObject);
        System.out.println(testedObject.toString());
        System.out.println(oppositeObject.toString());
    }
}

public class UserTest {

@Test

public void testEquals() {

User testedObject = new User(1L, "TEST", BigDecimal.ONE);

User oppositeObject = new User(1L, "TEST", BigDecimal.TEN);

assertEquals(oppositeObject, testedObject);

System.out.println(testedObject.toString());

System.out.println(oppositeObject.toString());

}

Аннотация @EqualsAndHashCode имеет ещё два параметра: первый, doNotUseGetters, указывает, как методы equals() и hashCode() должны получать данные, обращаясь напрямую к полям класса или вызывая соответствующие геттеры. Второй параметр, callSuper, гораздо интереснее — он указывает, надо ли при генерации методов equals() и hashCode() вызывать в них соответствующие методы базового класса.

Кроме того, @EqualsAndHashCode генерирует метод canEqual(), проверяющий, можно ли вообще сравнивать эти объекты. Потребность в canEqual() возникает из-за наследования классов: предположим у нас есть класс Point и класс ColoredPoint extends Point. Очевидно, что если мы сравним экземпляр ColoredPoint с экземпляром Point, они будут не эквивалентны. Но. Если мы сравним наоборот, экземпляр Point с ColoredPoint, то они внезапно станут эквивалентны, потому что Point сравнивает только те данные, о которых знает.

class Point {
int x;
int y;
//some manually written equals method
}

class ColoredPoint extend Point{
int color;
//some manually written equals method
}

class EqualsTest {
  @Test
  public void equalityFail() {
    ColoredPoint cp = new ColoredPoint(1,1,1);
    Point p = new Point(1,1);
    assertFalse(cp.equals(p));
    assertTrue(p.equals(cp));
  }
}

class Point {

int x;

int y;

//some manually written equals method

}

class ColoredPoint extend Point{

int color;

//some manually written equals method

}

class EqualsTest {

@Test

public void equalityFail() {

ColoredPoint cp = new ColoredPoint(1,1,1);

Point p = new Point(1,1);

assertFalse(cp.equals(p));

assertTrue(p.equals(cp));

}

canEqual() проверяет, совпадает ли тип объектов и корректно ли их сравнивать с учётом их положения в иерархии наследования.

toString()

Но вернёмся к lombok. В тесте класса User выводится результат toString():

User(id=1, name=TEST, value=1)
User(id=1, name=TEST, value=10)

1 2	User(id=1, name=TEST, value=1) User(id=1, name=TEST, value=10)

Такой красивый toString() генерирует аннотация @ToString, которая принимает те же самые параметры что и @EqualsAndHashCode и которые, очевидно, имеют точно такую же смысловую нагрузку. В поведении @ToString есть одно отличие — transient поля по умолчанию включены в вывод.

@Data

Но всё таки, даже с учётом аннотаций от project lombok, код класса User выглядит перегруженным. На простой класс с тремя полями у нас 10(!) аннотаций. Может быть, можно с этим что-то сделать? Аннотация @Data заменяет (почти) все вышеперечисленные аннотации! Она добавляет @Getter/@Setter ко всем полям, добавляет @EqualsAndHashCode и @ToString и создаёт конструктор для final и @NonNull полей. Поведение по умолчанию всех вышеперечисленных аннотаций сохраняется: геттеры/сеттеры будут публичными, static поля будут исключены из equals(), hashCode() и toString(), а transient поля будут исключены из equals() и hashCode(). Аннотации можно передать параметр of, чтобы сгенерировать статический метод для создания класса:

/**
 * Sample account entity.
 */
@Data(staticConstructor = "create")
public class Account {
    /**
     * Id.
     */
    @NonNull
    Long id;

    /**
     * Account owner.
     */
    @NonNull
    User owner;

    /**
     * Account's value.
     */
    BigDecimal amount;
}

/**

* Sample account entity.

@Data(staticConstructor = "create")

public class Account {

/**

* Id.

@NonNull

Long id;

/**

* Account owner.

@NonNull

User owner;

/**

* Account's value.

BigDecimal amount;

}

public class AccountTest {
    @Test
    public void testEquals() {
        User user = new User(1L, "TEST", BigDecimal.ONE);

        Account testedObject = Account.create(1L, user);
        Account opposieObject = Account.create(1L, user);

        assertEquals(testedObject, opposieObject);

        System.out.println(testedObject.toString());
        System.out.println(opposieObject.toString());
    }

    @Test
    public void testNotEquals() {
        User user = new User(1L, "TEST", BigDecimal.ONE);

        Account testedObject = Account.create(1L, user);
        Account opposieObject = Account.create(1L, user);

        testedObject.setAmount(BigDecimal.ONE);
        opposieObject.setAmount(BigDecimal.TEN);

        assertNotEquals(testedObject, opposieObject);

        System.out.println(testedObject.toString());
        System.out.println(opposieObject.toString());
    }
}

public class AccountTest {

@Test

public void testEquals() {

User user = new User(1L, "TEST", BigDecimal.ONE);

Account testedObject = Account.create(1L, user);

Account opposieObject = Account.create(1L, user);

assertEquals(testedObject, opposieObject);

System.out.println(testedObject.toString());

System.out.println(opposieObject.toString());

}

@Test

public void testNotEquals() {

User user = new User(1L, "TEST", BigDecimal.ONE);

Account testedObject = Account.create(1L, user);

Account opposieObject = Account.create(1L, user);

testedObject.setAmount(BigDecimal.ONE);

opposieObject.setAmount(BigDecimal.TEN);

assertNotEquals(testedObject, opposieObject);

System.out.println(testedObject.toString());

System.out.println(opposieObject.toString());

}

@Value и @Wither

@Value это @Data для неизменяемых (immutable) классов. Вместо того, чтобы художественно расставлять руками final, просто пишем @Value и получаем класс, в котором все поля private final, для них сгенерированны геттеры, equals(), hashCode(), toString() и конструктор, который тоже можно заменить статическим методом.

/**
 * Sample immutable entity.
 */
@Value
public class Group {
    /**
     * Id.
     */
    Long id;

    /**
     * User name.
     */
    @Wither
    String name;
}

/**

* Sample immutable entity.

@Value

public class Group {

/**

* Id.

Long id;

/**

* User name.

@Wither

String name;

}

Сеттеров такому классу, конечно же, не полагается. Но зато у него есть @Wither, который как сеттер, только для неизменяемых классов. Для переменных с аннотацией @Wither будет сгенерирован ммм виззер??? который вернёт копию объекта, с новым значением переменной:

public class GroupTest {

    @Test
    public void testEquals() {
        Group testedObject = new Group(1L, "TEST");
        Group oppositeObject = new Group(1L, "TEST");

        assertEquals(testedObject, oppositeObject);

        System.out.println(testedObject.toString());
        System.out.println(oppositeObject.toString());
    }

    @Test
    public void testNotEquals() {
        Group testedObject = new Group(1L, "TEST");
        Group oppositeObject = testedObject.withName("NEW");

        assertNotEquals(testedObject, oppositeObject);
        assertFalse(testedObject == oppositeObject);

        System.out.println(testedObject.toString());
        System.out.println(oppositeObject.toString());
    }
}

public class GroupTest {

@Test

public void testEquals() {

Group testedObject = new Group(1L, "TEST");

Group oppositeObject = new Group(1L, "TEST");

assertEquals(testedObject, oppositeObject);

System.out.println(testedObject.toString());

System.out.println(oppositeObject.toString());

}

@Test

public void testNotEquals() {

Group testedObject = new Group(1L, "TEST");

Group oppositeObject = testedObject.withName("NEW");

assertNotEquals(testedObject, oppositeObject);

assertFalse(testedObject == oppositeObject);

System.out.println(testedObject.toString());

System.out.println(oppositeObject.toString());

}

Код примера, за исключением Point и ColoredPoint, доступен на github.

equals() и hashCode()

toString()

@Data

@Value и @Wither

Рекомендованное чтение