Java Ready | Программирование

Почему Stream.toList() может сломать старый код?

В Java часто собирают stream в список:

List<String> names = users.stream()
        .map(User::name)
        .toList();

Выглядит почти так же, как старый вариант через Collectors:

List<String> names = users.stream()
        .map(User::name)
        .collect(Collectors.toList());

Но есть важное отличие.

Stream.toList() возвращает неизменяемый список:

List<String> names = users.stream()
        .map(User::name)
        .toList();

names.add("admin"); // UnsupportedOperationException

Если список нужен только для чтения, это даже плюс:

return users.stream()
        .filter(User::active)
        .map(User::name)
        .toList();

Так код явно показывает, что результат не должен случайно меняться после сборки.

Но если дальше список нужно дополнять, лучше создать изменяемую коллекцию явно:

List<String> names = users.stream()
        .map(User::name)
        .collect(Collectors.toCollection(ArrayList::new));

Или сделать копию:

List<String> names = new ArrayList<>(
        users.stream().map(User::name).toList()
);

👉 Java Ready | #совет

Интересная статья про реализацию Spring-подобного API на Java с нуля!

В этой статье:
• Как устроить простые аннотации для описания компонентов
• Как вручную искать классы и создавать объекты
• Как на базовом уровне реализовать идею dependency injection

Продолжай читать на Habr!

👉 Java Ready | #статья

Почему BigDecimal лучше не создавать из double?

BigDecimal часто используют для денег, процентов и точных вычислений:

BigDecimal price = new BigDecimal(0.1);

На первый взгляд всё нормально: хотели получить 0.1.

Но double хранит число в бинарном формате, и многие десятичные дроби там не представляются точно. Поэтому BigDecimal получает не “0.1”, а фактическое значение double.

Это легко увидеть:

System.out.println(new BigDecimal(0.1));

Результат может выглядеть примерно так:

0.100000000000000005551115123125...

Для точных десятичных значений лучше передавать строку:

BigDecimal price = new BigDecimal("0.1");

Или использовать valueOf(), если значение уже пришло как double:

BigDecimal price = BigDecimal.valueOf(0.1);

valueOf() берёт строковое представление double и обычно даёт ожидаемый десятичный результат.

Особенно важно помнить это в расчётах с деньгами:

BigDecimal total = new BigDecimal("19.99")
        .multiply(new BigDecimal("3"));

BigDecimal точный, но только если дать ему точное входное значение. Для денег и бизнес-логики не создавай его напрямую из double.

👉 Java Ready | #совет

Напоминалка по concurrent-коллекциям в Java!

Например, ConcurrentHashMap помогает безопасно работать с Map из нескольких потоков, а BlockingQueue удобна для схем producer/consumer.
На картинке шпаргалка по java.util.concurrent: concurrent lists/sets, ConcurrentMap, очереди, BlockingQueue, Deque и основным операциям добавления, удаления и просмотра элементов.

Сохрани, чтобы не потерять!

👉 Java Ready | #ресурс

Разбираем Collectors: 7 полезных приёмов для агрегации данных в Java!

Когда нужно не просто пройтись по списку, а сгруппировать элементы, собрать Map, посчитать статистику или подготовить вложенную структуру, обычного map/filter часто уже мало. Эти Collectors помогают писать компактнее и не превращать обработку коллекций в ручные циклы с временными Map и List.

👉 Java Ready | #шпора

Как в Java избежать лишней работы через Optional.orElseGet()?

Optional часто используют, чтобы взять значение или подставить fallback:

String name = userName.orElse(loadDefaultName());

На первый взгляд всё нормально. Но loadDefaultName() выполнится всегда, даже если внутри Optional уже есть значение.

Например:

Optional<String> name = Optional.of("Alice");

String result = name.orElse(expensiveFallback());

expensiveFallback() всё равно будет вызван.

Если fallback дорогой: запрос в базу, чтение файла, HTTP-вызов или тяжёлый расчёт — это лишняя работа.

Для ленивого fallback есть orElseGet():

String result = name.orElseGet(() -> expensiveFallback());

Теперь fallback выполнится только если Optional пустой:

Optional<String> empty = Optional.empty();

String result = empty.orElseGet(() -> expensiveFallback());

Разница особенно заметна в сервисном коде:

User user = cachedUser.orElseGet(() -> loadFromDatabase(id));

Если пользователь уже есть в кэше, база не трогается.

А orElse() лучше оставлять для простых готовых значений:

String label = name.orElse("Anonymous");

Если fallback нужно вычислять, используй orElseGet(). Если значение уже готово то orElse() вполне подходит.

👉 Java Ready | #совет

Java Design Patterns — большая база паттернов проектирования на Java!

На сайте собраны паттерны проектирования, архитектурные приёмы, принципы и готовые Java-примеры с объяснениями. Можно листать каталог по разделам, открывать конкретный паттерн, смотреть его идею, применимость, структуру и код. Есть не только классика вроде Factory, Builder, Adapter и Observer, но и более специфичные паттерны для enterprise-разработки, concurrency, integration и cloud-native подходов. Хороший ресурс, чтобы не просто заучивать названия паттернов, а видеть, как они выглядят в нормальном Java-коде.

Оставляю ссылочку: java-design-patterns.com

👉 Java Ready | #ресурс

Делаем простую валидацию DTO на Java!

Перед сохранением данных часто нужно проверить входной объект: email не пустой, возраст нормальный, имя задано. Соберём небольшую ручную валидацию без фреймворков.

Пусть есть DTO:

record CreateUserRequest(
    String email,
    String name,
    int age
) {}

Ошибки удобно хранить списком:

List<String> validate(CreateUserRequest request) {
    List<String> errors = new ArrayList<>();

Проверим обязательные строки:

    if (request.email() == null || request.email().isBlank()) {
        errors.add("email is required");
    }

    if (request.name() == null || request.name().isBlank()) {
        errors.add("name is required");
    }

Добавим простые бизнес-правила:

    if (request.age() < 18) {
        errors.add("age must be 18 or greater");
    }

    return errors;
}

Теперь код обработки становится понятным:

var errors = validate(request);

if (!errors.isEmpty()) {
    return errors;
}

Можно вынести повторяющуюся проверку в метод:

boolean blank(String value) {
    return value == null || value.isBlank();
}

И использовать короче:

if (blank(request.email())) {
    errors.add("email is required");
}

Ручная валидация полезна для небольших задач, CLI-утилит и мест, где не хочется тащить фреймворк. Главное, возвращать все ошибки сразу, а не падать на первой.

👉 Java Ready | #практика

Шпаргалка по регулярным выражениям в Java!

Например, \d ищет цифру, \w — word-символ, а Pattern.CASE_INSENSITIVE включает поиск без учёта регистра.

На картинке Java Regex: character classes, Pattern и Matcher, predefined classes, boundary matches, flags, quantifiers, groups, backreferences и logical operations.

Сохрани, чтобы не потерять!

👉 Java Ready | #совет

Полезная статья о том, как использовать RabbitMQ вместе с Java Spring!

В этой статье:
• Как два микросервиса могут общаться через очередь сообщений
• Что делают producer, consumer, exchange и queue
• Как собрать простой пример на Spring и RabbitMQ без лишней теории

Продолжай читать на Habr!

👉 Java Ready | #статья

Когда в Java стоит использовать Objects.requireNonNull()?

Иногда параметр метода не должен быть null вообще. Например, сервису нужен репозиторий, обработчику нужен клиент, а объекту доменной модели обязательное имя.

Часто это проверяют вручную:

public UserService(UserRepository repository) {
    if (repository == null) {
        throw new NullPointerException("repository");
    }

    this.repository = repository;
}

Работает, но код становится шумным.

В Java для такой проверки есть Objects.requireNonNull():

public UserService(UserRepository repository) {
    this.repository = Objects.requireNonNull(repository);
}

Если передать null, ошибка появится сразу в конструкторе, а не где-то позже при первом вызове метода.

Можно добавить понятное сообщение:

this.repository = Objects.requireNonNull(
    repository,
    "repository must not be null"
);

Это особенно полезно в конструкторах:

public Order(String id, BigDecimal amount) {
    this.id = Objects.requireNonNull(id, "id");
    this.amount = Objects.requireNonNull(amount, "amount");
}

И в методах, где null ломает смысл операции:

public void send(Message message) {
    Objects.requireNonNull(message, "message");

    transport.send(message);
}

Но не стоит ставить requireNonNull() везде подряд. Если null нормальный вариант состояния, лучше явно отразить это в логике:

String label = user.getNickname() != null
    ? user.getNickname()
    : user.getName();

Objects.requireNonNull() хорош там, где null является ошибкой. Он помогает падать раньше и ближе к месту неправильного вызова.

👉 Java Ready | #совет

📂 Напоминалка по структуре каталогов Linux!

Например, /bin содержит системные бинарные файлы, а /etc — конфигурации, управляющие поведением системы.

На картинке — директории Linux, их назначение и место в иерархии.

Сохрани, чтобы не забыть!

👉 Java Ready | #ресурс

Маскируем секреты в URL!

Нужно логировать ссылки без риска утечки токенов? Пишем небольшой санитайзер, который находит опасные query-параметры и заменяет их значения на ****.

В этой задаче:

• Разбираем URL через URI;
• Проверяем имена query-параметров;
• Скрываем token, password и api_key.

Такой подход помогает сохранять полезные логи для отладки, но не светить секреты в консоли, error reports и лог-файлах.

👉 Java Ready | #задача