Java Books

☕️ Spring Boot лайфхак: как не отправлять null поля в JSON

Если ваш API отдаёт JSON и там постоянно летят поля вида:

"phone": null,
"email": null

это:

- засоряет ответы
- увеличивает трафик
- мешает фронту (лишние проверки)

Решение - сказать Jackson: не сериализовать null-поля.

Достаточно добавить аннотацию на DTO:

✅ @JsonInclude(JsonInclude.Include.NON_NULL)

После этого все поля со значением null автоматически исчезнут из JSON-ответа.

Плюс: это особенно удобно для PATCH/частичных ответов.

Java-совет, который убивает “хитрые” баги в проде ⚠️

Самая коварная ошибка в Java - сравнение строк через `==`.

Почему это опасно:
- == сравнивает ссылки (объекты), а не текст
- иногда “работает” из-за String Pool, а иногда ломается в проде
- из-за этого появляются баги уровня: “на деве ок, в проде не ок”

Правило:
- ✅ для сравнения текста всегда equals()
- ✅ если строка может быть null - используй "CONST".equals(str)
- ✅ если нужно без учета регистра - equalsIgnoreCase()

Подписывайся, больше фишек каждый день !

❌ ПЛОХО: упадёт, если s == null
if (s.equals("OK")) {
    handle();
}

// ✅ ЛУЧШЕ: safe equals (null-safe)
if ("OK".equals(s)) {
    handle();
}

// ✅ Универсально: сравнение объектов + null-safe
if (Objects.equals(s, "OK")) {
    handle();
}

💡Java Совет : Helper-классы - да. “God class” - нет.

Хорошая практика в Java - выносить повторяющуюся логику в helper / utility классы.
Это делает код чище и уменьшает дублирование.

Но есть опасная крайность - God class:
класс, который “умеет всё” и постепенно превращается в помойку.

✅ Правильно (helper класс)
Например TextUtils, который делает только одну вещь:
- форматирование текста
- обработка строк
- простые операции над конкретной областью

❌ Плохо (God class)
Типичный DoThings, где впихнули всё подряд:
- работа с файлами
- логирование
- бизнес-операции
- управление задачами
- и ещё 20 методов “на всякий случай”

Почему это плохо:
- сложно тестировать
- сложно поддерживать
- сложно менять (ломается всё)
- растёт связанность и хаос

Правило:
Helper-класс должен иметь одну ответственность.
Если класс делает слишком много несвязанных вещей - разбивай на отдельные компоненты.

🔥 JAVA ПРОЕКТ ЗА 2 МИНУТЫ

Перед стартом делай правильно:
- Gradle/Maven сразу (без ручных jar)
- структура src/main/java + src/test/java
- JUnit + тесты с первого дня
- Checkstyle/Spotless чтобы код-стайл был единый
- .env / config для настроек (не хардкодь URL/ключи)

Так проект не развалится, когда станет больше 2 файлов.

Сохраняй себе это - и используй каждый раз, когда начинаешь новый Java-проект.

# Gradle проект с авто-структурой
mkdir my_java_app && cd my_java_app
gradle init --type java-application --dsl groovy --test-framework junit-jupiter

# быстрый запуск + тесты
./gradlew test
./gradlew run

🔥 Хочешь прокачаться в аналитике, но не просто читать теорию, а решать реальные задачи?

Мы запустили полностью бесплатный телеграм-тренажёр 👇

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

Что внутри:

✔ живые кейсы из реальной практики
✔ удобный симулятор - как работа в компании, только бесплатно
✔ разбор ошибок — понимаешь не только «как», но и «почему»
✔ добавляем задачи с интервью и улучшаем бот вместе с сообществом

Начни тренироваться сегодня — и почувствуй уверенность в работе с данными.

t.me/Analitics_databot

🖥 Java: `Stream.peek()`- только для отладки

Есть простой принцип, который часто ломают.

peek() — не для логики.
Его задача — подсмотреть, что проходит по конвейеру, и помочь отладке.

Пример — посмотреть, как меняются данные по шагам:

list.stream()
    .filter(x -> x > 10)
    .peek(x -> System.out.println("Filter: " + x))
    .map(x -> x * 2)
    .peek(x -> System.out.println("Map: " + x))
    .toList();

Вот, как это работает:

- filter() — отбрасывает лишнее
- peek() — просто печатает, ничего не меняя
- map() — преобразует значения

Почему важно не класть туда «настоящую» логику:

- peek() могут удалить или отключить
- порядок выполнения потоков может меняться
- код становится хрупким и непредсказуемым

Коротко:
- нужен вывод - используй peek().
- нужна логика - используй map(), filter() и другие операторы.

🖥 Java-совет, который часто экономит ресурсы

orElseGet() вместо orElse(), когда значение считать дорого

Многие пишут так:

User user = cache.find(id).orElse(createDefaultUser());

Проблема: createDefaultUser() выполнится всегда,
даже если пользователь нашёлся в кэше.

Правильнее так:

User user = cache.find(id).orElseGet(() -> createDefaultUser());

💡 В чём фишка

orElse() сначала вызывает аргумент, потом проверяет Optional

orElseGet() вызывает лямбду только если значение пустое

📌 Когда это особенно важно

- создание объектов «по умолчанию» дорогое
- требуется загрузка из БД/сети
- есть тяжёлая сериализация или вычисления

Spring Boot Tip: тестируем REST проще с `RestTestClient` 🚀

В Spring Boot можно легко писать интеграционные тесты для REST-эндпоинтов,
используя `RestTestClient` вместе с аннотацией:

@AutoConfigureRestTestClient

Это автоматически настраивает клиент и позволяет:
- отправлять запросы прямо из тестов
- проверять статус и тело ответа
- работать с объектами, а не “сырым” JSON

Пример

Копировать код
@SpringBootTest
@AutoConfigureRestTestClient
public class PersonControllerTests {

    private static final String API_PATH = "/persons";

    @Test
    void add(@Autowired RestTestClient restTestClient) {
        restTestClient.post().uri(API_PATH)
            .body(Instancio.create(Person.class))
            .exchange()
            .expectStatus().is2xxSuccessful()
            .expectBody(Person.class)
            .value(person -> assertNotNull(person.getId()));
    }
}

👉 Для TestRestTemplate есть похожая аннотация:

@AutoConfigureTestRestTemplate

Тесты становятся чище, короче и ближе к реальному поведению API ✨

💡 Java совет: рекурсивная обработка файлов с Files.walk()

Если нужно пройтись по всем файлам в директории и её подкаталогах, не пиши рекурсию вручную — используй Files.walk().

Пример: найти все `.java`-файлы в проекте

Path startPath = Paths.get("src");

try (Stream<Path> paths = Files.walk(startPath)) {
    paths
        .filter(Files::isRegularFile)
        .filter(path -> path.toString().endsWith(".java"))
        .forEach(System.out::println);
} catch (IOException e) {
    e.printStackTrace();
}

Почему это хороший подход:

- Рекурсивный обход «из коробки»
- Работает через Stream API
- Легко фильтровать, маппить и агрегировать
- Автоматически закрывает ресурсы (try-with-resources)

Полезно для:

- анализа исходников
- линтеров и кодогенерации
- поиска файлов по расширению
- утилит и dev-скриптов

#Java #IO

🧠JAVA ИСПОЛЬЗУЙ TREESET ПРАВИЛЬНО #java

Если в Java нужно убрать дубликаты из списка и отсортировать элементы - используй TreeSet. Он автоматически удаляет повторяющиеся значения и сортирует их либо по естественному порядку, либо по кастомному правилу через Comparator.

Естественный порядок
List<String> colors = Arrays.asList("red", "green", "red", "orange", "turquoise");
Set<String> colorsSet = new TreeSet<>(colors);
for (String color : colorsSet) {
    System.out.println(color);
}

Сортировка по длине строки
Comparator<String> byLength = Comparator.comparingInt(String::length);
Set<String> sortedSet = new TreeSet<>(byLength);
sortedSet.addAll(colors);
for (String color : sortedSet) {
    System.out.println(color);
}

💡 Java совет:

Начиная с Java 19, можно использовать *виртуальные потоки* - лёгкие потоки, которые управляются самой JVM, а не операционной системой.

Что это даёт:

- можно запускать тысячи и даже миллионы задач без нагрузки на ОС
- проще писать высоконагруженные приложения без сложной асинхронности
- более понятный и чистый код по сравнению с CompletableFuture и callback-подходами

Виртуальные потоки — главный шаг Java к масштабируемой конкурентности.

#Java #JavaDev

🔥 Server Survival: Стройте облачную инфраструктуру!

Играйте в интерактивную 3D-симуляцию, где вы - облачный архитектор. Стройте и масштабируйте облачную инфраструктуру, защищаясь от DDoS-атак и управляя бюджетом. Цель — выжить как можно дольше, обрабатывая легитимный трафик и избегая потерь репутации.

🚀Основные моменты:
- Управление бюджетом и репутацией.
- Разные типы трафика: веб, API и мошеннический.
- Режимы игры: выживание и песочница для экспериментов.
- Улучшение сервисов для повышения производительности.
- Интуитивное управление и визуальная обратная связь.

📌 GitHub: https://github.com/pshenok/server-survival

📌 Durable Execution Engine на SQLite:

• Durable Execution (DE) - это подход, который позволяет выполнять длинные многошаговые процессы так, чтобы после сбоя можно было продолжить с последнего успешного шага, а не запускать всё заново.

• В статье показан простой Proof of Concept - Persistasaurus: лёгкий DE-движок на Java, который использует SQLite как хранилище состояния.

• Потоки (flows) пишутся как обычный Java-код: методы помечаются аннотациями @Flow и @Step, а их прогресс автоматически сохраняется. Если процесс падает, можно безопасно перезапустить его без повторного выполнения шагов.

• Идея не новая, но современная Java + SQLite позволяют сделать удивительно компактное и понятное решение без тяжёлой инфраструктуры.

Почему это полезно:

• Упрощает работу с долгоживущими процессами
• Избавляет от повторных вычислений и экономит ресурсы
• Подходит для прототипов, внутренних сервисов и задач средней сложности

Что учитывать:

• Это только прототип - для реальных больших систем нужно масштабирование, отказоустойчивость, параллелизм и дополнительные инструменты
• SQLite отлично подходит для простых сценариев, но не для высоконагруженных распределённых систем

🔗 Читаем тут: morling.dev/blog/building-durable-execution-engine-with-sqlite/

🚀 Spring Batch совет

Хочешь контролировать, сколько раз может стартовать конкретный шаг в Spring Batch? Используй параметр startLimit — он задаёт максимальное число запусков для step'а.

Полезно для случаев с повторными попытками, защитой от бесконечного рестарта и строгим контролем бизнес-логики.

Quick Java

📚 Book

🚀 В Spring Boot можно точечно отключать ненужную автоконфигурацию через аннотацию
**@SpringBootApplication(exclude = …)**.

Это удобно, когда в проекте есть своя кастомная конфигурация, которая конфликтует с дефолтной, или когда вы хотите убрать лишние автоматические настройки и контролировать поведение вручную.

Так вы оставляете только нужные части автоконфигурации и избегаете скрытых конфликтов.

#SpringBoot #JavaDev