Поддержка переменного числа аргументов (varargs) была добавлена в Java, начиная с версии JDK 5 (Java 5). До этого программисту приходилось либо перегружать методы для разного количества параметров, либо передавать массив аргументов вручную.

Иными словами - если у Вас возникает случай, что в метод может поступать неопределенное количество параметров, в том числе и разного типа, но метод должен быть только ОДИН - Varargs Ваш выбор 🤙

void foo(Object... data) { /*...*/ }

void foo(Object[] data) { /*...*/ }

public static void printStrings(String... words) {
    for (String w : words) {
        System.out.print(w + " ");
    }
    System.out.println();
}

// Вызовы:
printStrings("Alice", "Bob");
printStrings("one", "two", "three");

При этом внутри words будет String[] со всеми переданными значениями

public static void printAll(Object... args) {
    for (Object o : args) {
        System.out.print(o + " ");
    }
    System.out.println();
}

// Вызов:
printAll("Hello", 123, true, new User("Tom"));

Приведение типов и автопакетирование

Метод void m(Object... args) под капотом видит args как Object[]. Если вы ожидаете внутри определённый тип, будьте осторожны с приведением, иначе может возникнуть ClassCastException. Попытка привести Object[] к String[] при неправильном использовании varargs приведёт к ошибке времени выполнения.

Ещё один нюанс – работа с примитивными типами и их обёртками: varargs не применяет автопакетирование к массивам примитивов. То есть если вы ожидаете набор чисел, стоит использовать Integer... вместо int..., иначе передача int[] в параметр типа Object... будет воспринята как единичный объект int[], а не как набор чисел.

Конфликт с перегрузкой методов

Перегрузка методов вместе с varargs может привести к неоднозначности. Так, если объявлены оба метода fun(int... a) и fun(boolean... b), то вызов fun() без аргументов компилятор посчитает неразрешимым, ведь он не может однозначно выбрать, какую версию вызывать.

Аналогично, комбинация fun(int... a) и fun(int n, int... a) приводит к конфликту при вызове fun(1), потому что компилятор не знает, вызвать ли первый метод с одним элементом или второй метод с фиксированным первым параметром. Такие неоднозначности приводят к ошибкам компиляции. Чтобы этого избежать, не перегружайте методы только за счёт varargs: лучше дать методам разные имена или явно менять количество параметров.

@Entity
public class User {
    //стандартные поля
    @OneToMany(mappedBy = "owner", fetch = FetchType.LAZY)
    private List<Car> cars = new ArrayList<>();
}

@Entity
public class Car {
    //стандартные поля
    @ManyToOne
    @JoinColumn(name = "owner_id")
    private User owner;
}

Page<User> users = userRepository.findAll(specification, PageRequest.of(0, 10));

return (root, query, cb) -> {
    root.fetch("cars", JoinType.LEFT);
    query.distinct(true);
    return cb.conjunction();
};

Page<User> users = userRepository.findAll(specification, PageRequest.of(0, 10));

root.fetch("cars", JoinType.LEFT);

criteriaQuery.distinct(true);

SELECT u.*, r.* FROM users u
LEFT JOIN roles r ON r.user_id = u.id

@Entity
public class User {
    //стандартные поля
    @OneToMany(mappedBy = "owner")
    @BatchSize(size = 50)
    private List<Car> cars = new ArrayList<>();
}
Количество запросов существенно уменьшится — на тот размер size, который мы задали. Это значит, что проблема N+1 решена.

@EntityGraph(attributePaths = {"cars"})
Page<User> findAll(Pageable pageable);

"При пяти загружаемых коллекциях производительность разделенного запроса с @EntityGraph хуже в 2 раза. При десяти — в 45 раз. А при загрузке 15 коллекций — в 1401 раз! На графике нет данных по разделенному запросу для 20 коллекций, так как я просто-напросто получил ошибку OutOfMemoryError."

С @BatchSize же никаких JOIN не происходит, и при добавлении дополнительной коллекции с ассоциацией @OneToMany просто добавляются дополнительные select для этой коллекции.

@Query(value = """
    SELECT u.id AS userId, u.name AS userName, c.model AS carModel
    FROM user u
    LEFT JOIN car c ON c.owner_id = u.id
    WHERE (:name IS NULL OR u.name ILIKE %:name%)
    ORDER BY 
        CASE WHEN :sortBy = 'name' THEN u.name
             WHEN :sortBy = 'id' THEN CAST(u.id AS TEXT)
             ELSE u.name
        END ASC
    LIMIT :limit OFFSET :offset
""", nativeQuery = true)
List<UserCarDTO> findWithFilters(
    @Param("name") String name,
    @Param("sortBy") String sortBy,
    @Param("limit") int limit,
    @Param("offset") int offset
);

@Query(value = """
    SELECT COUNT(DISTINCT u.id)
    FROM user u
    WHERE (:name IS NULL OR u.name ILIKE %:name%)
""", nativeQuery = true)
long countUsers(@Param("name") String name);

@Entity
@Data
public class Employee {
    @Id
    private Long id;
    private String name;
    
    @OneToOne
    @JoinColumn(name = "workstation_id")
    private Workstation workstation;
    
    @ManyToOne
    @JoinColumn(name = "department_id")
    private Department department;
}

@Entity
@Data
public class Workstation {
    @Id
    private Long id;
    private String number;  // Поле для сортировки
}

@Entity
@Data
public class Department {
    @Id
    private Long id;
    private String name;  // Поле для сортировки
}

@Query("SELECT e FROM Employee e WHERE e.name = :name")
Page<Employee> findByName(@Param("name") String name, Pageable pageable)

Естественно поля могут передаваться таким образом:
Pageable pageable = PageRequest.of(0, 10, Sort.by(Sort.Direction.fromString("workstation.number"));

или

Pageable pageable = PageRequest.of(0, 10, Sort.by(Sort.Direction.fromString("department.name"));

SELECT e.* FROM employee e
JOIN workstation w ON e.workstation_id = w.id
WHERE e.name = 'John'
ORDER BY w.number ASC  -- Сортировка применяется

@Query("SELECT e FROM Employee e " +
       "LEFT JOIN e.department d " +  // Явное соединение
       "WHERE e.name = :name " +
       "ORDER BY d.name")  // Сортировка в запросе(но не обязательно)
Page<Employee> findByNameWithDepartmentSort(
    @Param("name") String name, 
    Pageable pageable);

@Query("SELECT DISTINCT e FROM Employee e " +
       "LEFT JOIN FETCH e.department d " +  // Загружаем department сразу
       "WHERE e.name = :name " +
       "ORDER BY d.name")
Page<Employee> findByNameWithDepartmentFetch(
    @Param("name") String name, 
    Pageable pageable);

public interface EmployeeRepository extends 
    JpaRepository<Employee, Long>, 
    JpaSpecificationExecutor<Employee> { }

// В сервисе:
Specification<Employee> spec = (root, query, cb) -> {
    Join<Employee, Department> department = root.join("department");
    return cb.equal(root.get("name"), name);
};

Sort sort = Sort.by("department.name").ascending();
Pageable pageable = PageRequest.of(0, 10, sort);

Page<Employee> result = repository.findAll(spec, pageable);