🧠 Трюк с @Configuration и @ComponentScan: как не словить баг при миграции на Spring Boot 3+

Когда вы выносите конфигурацию в отдельный модуль или создаёте библиотеку с @Configuration-классами — не забывайте:

📌 Spring Boot 3+ по умолчанию НЕ сканирует пакеты вне стартового (main).

Пример:

// Внутри библиотеки
@Configuration
public class MyLibConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

И вы такие:

@SpringBootApplication
public class App {
    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

🔥 Но MyService не создаётся! Почему?

💡 Потому что @ComponentScan по умолчанию сканирует ТОЛЬКО package текущего класса и ниже.

📌 Решения:

1. Ручной импорт конфигурации:

@SpringBootApplication
@Import(MyLibConfig.class)
public class App { ... }

2. Сделать конфигурацию @AutoConfiguration и подключить через spring.factories или META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports — актуально для библиотек.

3. Переместить MyLibConfig в подпакет стартового класса (не всегда возможно или удобно).

⚠️ Часто баг проявляется неявно: контекст стартует, но бины "теряются", и вы получаете NoSuchBeanDefinitionException в рантайме.

✅ После миграции на Spring Boot 3+ обязательно проверьте, что нужные конфигурации действительно подхватываются. Особенно, если раньше они подключались "магически".

👉@BookJava

🔧 Maven vs. Gradle: что выбрать разработчику?

Когда речь заходит о сборке Java-проектов, выбор обычно падает на два главных инструмента: Maven и Gradle. Оба давно стали стандартом индустрии, но каждый имеет свои особенности. Разберёмся, что выбрать 👇

☕ Maven — проверенная классика

✅ Строгая структура: легче читать и сопровождать
✅ Надёжность и предсказуемость сборки
✅ Большое комьюнити и множество плагинов
⚠️ XML-конфигурация громоздкая
⚠️ Медленнее по сравнению с Gradle

⚡ Gradle — гибкость и скорость

✅ Поддержка Kotlin и Groovy DSL
✅ Инкрементальные сборки и кэширование → быстрее
✅ Более гибкий подход к настройке
⚠️ Порог входа выше
⚠️ Иногда сложно отлаживать конфигурацию


💡 Вывод:

* 🔹 Выбирай Maven, если важны стабильность, простота и читаемость.
* 🔹 Выбирай Gradle, если хочешь максимум производительности и гибкости.

🎯 В крупных проектах Gradle становится всё популярнее, особенно при использовании Kotlin. Но в enterprise-среде Maven по-прежнему правит бал.

А ты чем пользуешься? Делись опытом в комментах ⬇️

👉@BookJava

💡 Чем опасен @Scheduled(fixedRate) без @Transactional?

Расписание в Spring через @Scheduled — удобный способ запускать задачи по таймеру. Но часто разработчики забывают про транзакции, особенно с fixedRate, и попадают в ловушку.

📌 Пример проблемы:

@Scheduled(fixedRate = 10_000)
public void cleanUp() {
    List<Job> jobs = jobRepository.findAllByStatus(PENDING);
    jobs.forEach(job -> {
        job.setStatus(PROCESSING);
        jobRepository.save(job);
    });
}

🧨 Каждые 10 секунд метод запускается заново. Если выполнение предыдущего ещё не закончено, начнётся второй поток, который заберёт те же PENDING -записи.
В итоге — дублирование обработки, гонки, повреждение данных.

📉 Особенно критично при долгих задачах или высокой нагрузке.

✅ Решение — обернуть метод в транзакцию + использовать блокировки:

@Transactional
@Scheduled(fixedRate = 10_000)
public void cleanUp() {
    List<Job> jobs = jobRepository.findAllByStatusForUpdate(PENDING); // SELECT ... FOR UPDATE
    jobs.forEach(job -> {
        job.setStatus(PROCESSING);
        jobRepository.save(job);
    });
}

📌 Или добавить флаг “locked”, чтобы явно помечать взятые задачи.

💡 Лучше использовать @Scheduled(fixedDelay) — он ждёт завершения предыдущего запуска. Это безопаснее по умолчанию.

🧠 Подумайте о том, чтобы заменить @Scheduled на:

* Spring Batch (если сложные джобы)
* Spring Integration / Flowable / Camunda (если нужны гарантии и retry)
* Quartz (если нужен контроль и очереди)

👉@BookJava

❓Хотите овладеть Spark на профессиональном уровне?

Приглашаем дата-инженеров 26 мая в 20:00 на открытый урок «Spark в Kubernetes».

На занятии мы рассмотрим особенности и варианты запуска Spark в Kubernetes.

🔊 Вебинар проведет Вадим Заигрин, Team Lead команд инженеров данных на разных проектах.

Продолжить освоение инструментов дата-инжиниринга вы сможете на онлайн-курсе «Spark Developer» от OTUS.

➡️ Ссылка для регистрации: https://vk.cc/cLWZuO

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🧠 Внезапная ловушка с @Transactional и self-invocation в Spring

Вы знали, что вызов метода с @Transactional внутри того же класса не активирует транзакцию? Это один из самых частых подводных камней.

📌 Почему так происходит?
Spring AOP работает через прокси. Когда вы вызываете метод this.someTransactionalMethod(), вы обходите прокси и вызываете метод напрямую — без обёртки, которая включает транзакцию.

Пример:

@Service
public class UserService {

    public void createUser() {
        // транзакция не начнётся
        this.saveUser(); 
    }

    @Transactional
    public void saveUser() {
        // ожидаем, что тут будет транзакция, но её нет
    }
}

⚠️ Итог: никакой транзакции, и вы получите баг, который сложно заметить: данные не откатываются, lazy-loading кидает LazyInitializationException, и т.д.

💡 Как правильно:

1. Вынести transactional-метод в другой бин:

@Service
public class UserSaver {
    @Transactional
    public void saveUser() { ... }
}

2. Или получить прокси текущего бина через AopContext:

public void createUser() {
    ((UserService) AopContext.currentProxy()).saveUser();
}

📌 Для второго варианта не забудьте включить:

@EnableAspectJAutoProxy(exposeProxy = true)

⚠️ Важно: Не используйте AopContext без крайней необходимости. Предпочтительнее делегировать логику в отдельный бин — это чище и легче тестируется.

👉@BookJava

🧠 Как не словить LazyInitializationException в Spring Boot + Hibernate

Одна из самых частых ошибок при работе с JPA:

org.hibernate.LazyInitializationException: failed to lazily initialize a collection

📌 Причина: лениво загружаемая коллекция (LAZY) обращается к БД вне транзакции — например, в слое контроллера или после закрытия Session.

💡 Как избежать?

✅ Решение 1: @Transactional в сервисе

Убедитесь, что вы обращаетесь к ленивым коллекциям внутри метода с @Transactional:

@Transactional
public UserDto getUser(Long id) {
    User user = userRepository.findById(id)
        .orElseThrow();

    // OK: коллекция friends будет инициализирована в транзакции
    return new UserDto(user.getName(), user.getFriends());
}

⚠️ Не используйте @Transactional в контроллерах — это плохая практика.



✅ Решение 2: Fetch Join

Подгрузите нужные данные сразу через JOIN FETCH:

@Query("SELECT u FROM User u LEFT JOIN FETCH u.friends WHERE u.id = :id")
Optional<User> findByIdWithFriends(@Param("id") Long id);

📌 Плюс: 1 запрос вместо N (N+1 проблема решается).
📌 Минус: может быть избыточная загрузка, особенно с большими коллекциями.



✅ Решение 3: DTO проекция

Лучший способ в большинстве случаев — проецировать сразу в DTO:

@Query("""
    SELECT new com.example.UserDto(u.name, f.name)
    FROM User u
    LEFT JOIN u.friends f
    WHERE u.id = :id
""")
List<UserDto> findUserWithFriendNames(@Param("id") Long id);

📌 Выгружает только нужные данные. Быстро, безопасно, эффективно.


💬 Ленивая инициализация — ок, если вы контролируете границы транзакций.
Проекции и fetch join — ваши лучшие друзья, если нужен контроль и производительность.

👉@BookJava

🔥 Java и производительность — новая тема от онлайн-конференции Podlodka Java Crew

С 26 по 30 мая вас ждет тематическая неделя, посвящённая продвинутым практикам оптимизации Java-приложений.

В программе:

— Доклад Владимира Плизги (Tibbo System) о подходах к профилированию и инструментах, которые действительно работают;

— Воркшоп по JMH от Григория Кошелева (Контур) — научитесь писать микробенчмарки правильно;

— Круглый стол с Антоном Курако (Т-Банк) и Михаилом Поливахой (Spring АйО) — сравнение Spring, Micronaut, Quarkus и Kora через призму производительности;

— Опыт команды НСПК по нагрузочному тестированию в бою — расскажет Павел Митин.

А ещё — JFR, корутины, Kubernetes и десятки инсайтов из продакшена.

🎯 Неделя для тех, кто держит перформанс под контролем.

🔗 Подключайся: podlodka.io/javacrew

🧠 Трюк с @EventListener в Spring — убираем лишний @TransactionalEventListener

Когда тебе нужно обрабатывать события в рамках транзакции, мы часто пишем:

@TransactionalEventListener
public void handleEvent(MyEvent event) {
    // ...
}

⚠️ Но есть нюанс: @TransactionalEventListener по умолчанию срабатывает после коммита. Иногда это не очевидно и вызывает баги, особенно если ожидаешь, что событие обработается внутри транзакции.

📌 Альтернатива: обычный @EventListener, но вместе с TransactionSynchronizationManager.

💡 Сниппет:

@Component
public class MyEventHandler {

    @EventListener
    public void handle(MyEvent event) {
        if (TransactionSynchronizationManager.isActualTransactionActive()) {
            TransactionSynchronizationManager.registerSynchronization(
                new TransactionSynchronizationAdapter() {
                    @Override
                    public void afterCommit() {
                        // обработка события после коммита
                    }
                }
            );
        } else {
            // fallback: нет активной транзакции — выполняем сразу
        }
    }
}

📎 Плюсы:
— Лучше контроль: ты сам решаешь, когда обрабатывать (до/после/вне транзакции)
— Можно централизовать поведение через utility-метод
— Гибкость: логика обработки не зависит от аннотаций Spring'а

⚠️ Минус: чуть больше кода, но понятнее поведение.

👉@BookJava

🧠@Value vs @ConfigurationProperties — не выбирай наобум

Оба способа хороши для конфигурации, но используют их по-разному. И если ты всё ещё везде пихаешь @Value, держи краткий гайд, когда лучше что:


📌 @Value — просто, но не гибко:

@Value("${my.prop}")
private String value;

✅ Хорошо для единичных значений
❌ Плохо для сложных структур, списков, валидации
❌ Трудно покрыть тестами (без TestPropertySource)
❌ Нет биндинга по префиксу → нет группировки



📌 @ConfigurationProperties — сила и масштаб:

@ConfigurationProperties(prefix = "app.feature")
public class FeatureProperties {
    private boolean enabled;
    private List<String> items;
}

💡 Используй с @EnableConfigurationProperties или аннотируй как @Component

✅ Удобно группировать и документировать
✅ Работает с вложенными структурами, коллекциями
✅ Поддерживает JSR-303 валидацию (@Validated)
✅ Легче мокать в тестах
✅ Интеграция с Spring Boot Actuator (/actuator/configprops)


⚠️ Не смешивай: не нужно тянуть @Value внутрь @ConfigurationProperties — это антипаттерн.


💬 Если конфигурация простая — @Value норм. Но как только появляется структура, коллекции, логика — всегда используй @ConfigurationProperties.

👉@BookJava

🚀 Открой для себя идеальный путь к лидерству с карьерным тестом от ОЭЗ «Алабуга»! 🌟

Мечтаете о карьере в крупной компании, где ваш потенциал раскроется на полную? Наш тест поможет вам определить вашу уникальную лидерскую роль. Может быть, именно вы станете тем лидером, который выведет команду на новый уровень?

После прохождения теста вы можете заполнить заявку и получить приглашение на эксклюзивную лидерскую программу. Участие в программе открывает реальные перспективы трудоустройства в ОЭЗ «Алабуга», предоставляя шанс начать путь к профессиональному признанию.

Сделайте первый шаг к своему будущему сегодня! Пройдите тест, подайте заявку и начните строить свою карьеру вместе с нами. 🎯

Double-brace инициализация в Java — это идиома, которая используется для инициализации коллекций (и иногда других объектов) в краткой форме. Она выглядит как две открывающие фигурные скобки подряд {{ и имеет специфическое поведение. Пример:

import java.util.*;

List<String> list = new ArrayList<String>() {{
    add("one");
    add("two");
    add("three");
}};

Как это работает:

Double-brace инициализация — это комбинация двух конструкций:

1. Анонимный внутренний класс:

   new ArrayList<String>() { ... }
   

Создаётся новый безымянный подкласс ArrayList.

2. Инициализатор экземпляра:

   {{ ... }}
   

Это блок, который выполняется при создании объекта. В него можно вставлять вызовы методов (например, add()).

Преимущества:

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

  private static final Set<String> set = new HashSet<>() {{
      add("A");
      add("B");
  }};
  

Недостатки:

1. Создаётся лишний анонимный класс — это увеличивает количество байткода и может мешать сериализации.
2. Утечки памяти — если такой класс находится внутри внешнего класса, он может неявно хранить ссылку на него.
3. Читаемость — не все разработчики знают, как это работает, и это может сбивать с толку.
4. Нарушение принципов OOP — логика инициализации размещается в конструкторе, который не явно виден.

Альтернативы:

Java 8+ (через Stream и Collectors):

List<String> list = Stream.of("one", "two", "three")
                          .collect(Collectors.toList());

Статический метод инициализации:

public static List<String> createList() {
    List<String> list = new ArrayList<>();
    list.add("one");
    list.add("two");
    return list;
}

Java 9+ (immutable):

List<String> list = List.of("one", "two", "three");
Set<String> set = Set.of("A", "B");

Вывод:

Double-brace инициализация — это удобный, но потенциально опасный трюк, который не рекомендуется использовать в продакшене. Лучше предпочесть более читаемые и безопасные альтернативы, особенно с учётом новых возможностей Java 8+.

👉@BookJava

📌 picocli — это современная библиотека для создания CLI-приложений на Java. Она упрощает разработку командных интерфейсов, обеспечивая:

* Автоматическую генерацию --help и --version
* Поддержку подкоманд (как в git commit, git push)
* Аргументы, параметры, опции с короткими и длинными флагами (-v, --verbose)
* Интеграцию с GraalVM (подходит для нативной компиляции)
* Поддержку аннотаций (аннотируй POJO — и готово!)
* Автоматическую валидацию аргументов
* Цветной вывод и гибкое форматирование
* Интерактивный режим и автодополнение

Проект активно развивается, полностью документирован и используется в сотнях продакшн-проектов. Если ты ищешь мощную и простую в использовании CLI-библиотеку на Java — picocli отличный выбор.

https://github.com/remkop/picocli

👉@BookJava

Что такое механизм try-with-resources?

Механизм try-with-resources в Java — это конструкция, которая упрощает работу с ресурсами, требующими закрытия (например, файлы, сокеты, соединения с БД и т.д.). Он автоматически закрывает ресурсы после завершения блока try, избавляя от необходимости писать finally вручную.

📌 Поддерживается с Java 7
📌 Ресурсы должны реализовывать интерфейс AutoCloseable

💡 Пример:

try (BufferedReader reader = new BufferedReader(new FileReader("file.txt"))) {
    String line = reader.readLine();
    System.out.println(line);
} catch (IOException e) {
    e.printStackTrace();
}
// reader будет закрыт автоматически, даже если произойдёт исключение

🧠 Почему это важно:

* Уменьшает boilerplate-код
* Исключает утечки ресурсов
* Упрощает обработку исключений

⚠️ Совет:

С Java 9 можно использовать уже объявленные переменные, если они final или effectively final:

BufferedReader reader = new BufferedReader(new FileReader("file.txt"));
try (reader) {
    System.out.println(reader.readLine());
}

👉@BookJava