Понимание разницы между Error и Exception в Java ✅

Что такое Error в Java?
- Error (ошибка) в Java представляет собой серьёзные проблемы, которые программа не должна пытаться обрабатывать. Такие ошибки, как правило, генерируются виртуальной машиной Java (JVM) и указывают на сбои, не зависящие от кода программы — например, утечки памяти или переполнение стека.

Что такое Exception в Java?
- Exception (исключение) — это ситуации, которые программа может предсказать и обработать. Это ошибки, от которых можно восстановиться во время выполнения с помощью механизмов обработки исключений, таких как конструкции try-catch.

👉@BookJava

❓ Java-разработчики, уже пробовали работать с асинхронным кодом через Scala Future?

⏰ 15 апреля в 18:30 на открытом вебинаре Валентин Шилин расскажет, как эффективно использовать Future в Scala: избегать ошибок (блокировки, потеря контекста), комбинировать асинхронные операции (Future.sequence, traverse, for-comprehensions) и улучшать производительность кода.

Валентин — старший программист и аналитик данных Deutsche Telekom IT GmbH, эксперт в обработке больших данных и преподаватель курсов по Scala и Apache Spark.

Если вы используете Java и хотите перейти на Scala, или уже работаете с Play Framework, Akka или Spark, — вебинар точно для вас. Научитесь грамотно писать асинхронный код, избегая типичных проблем.

🎁 Все участники смогут задать вопросы эксперту и получат скидку на полный курс по Scala-разработке.

👉 Регистрируйтесь и повысьте эффективность своей работы

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

🎯 Как Java находит классы? Под капотом ClassLoader'ов

Сечас покажу вам одну из самых недооценённых тем в мире Java — механизм загрузки классов.

Когда ты запускаешь Java-приложение, оно не просто «видит» все классы. За кулисами работает цепочка загрузчиков:

1. Bootstrap ClassLoader
Самый базовый. Загружает классы из JDK (rt.jar, java.base, и так далее). На него даже нельзя получить ссылку в коде.

2. Platform ClassLoader (ранее Extension)
Загружает модули платформы (jmods), доступные из JDK, но не из java.base.

3. Application ClassLoader
Твой лучший друг. Он отвечает за загрузку классов из classpath (например, target/classes и lib/*.jar).

Но вот где начинается магия — ты можешь создать собственный ClassLoader и загружать классы в рантайме из файлов, БД или даже сети. Например:

ClassLoader customLoader = new URLClassLoader(new URL[]{new File("plugins/").toURI().toURL()});
Class<?> pluginClass = customLoader.loadClass("com.example.PluginImpl");

💡 Это используется в плагинных системах (например, IntelliJ, Jenkins, Minecraft).
Но будь осторожен — неправильная работа с загрузчиками может привести к ClassCastException, даже если классы выглядят одинаково.

👉@BookJava

🔍 Как дебажить ClassLoader-проблемы в Java

В прошлом посте я рассказывал, как работает механизм загрузки классов в JVM. Сегодня разберём, как дебажить проблемы, которые возникают из-за загрузчиков. А это, между прочим, один из самых частых источников боли в больших проектах.

🧨 Типичная проблема:

ClassCastException: class com.example.MyClass cannot be cast to class com.example.MyClass

Текст ошибки одинаковый класс... но JVM считает их разными. Почему?

👉 У каждого Class в JVM есть два признака уникальности:
1. Полное имя (com.example.MyClass)
2. Загрузчик (ClassLoader)

Если один и тот же класс загружен разными загрузчиками, JVM считает, что это разные классы. Отсюда и ошибки.

🛠 Как дебажить:
1. Вывести загрузчик:

   System.out.println(myObject.getClass().getClassLoader());
   

2. Сравнить загрузчики:
Убедись, что два экземпляра класса загружены одним и тем же ClassLoader.

3. JVM-флаги:
Добавь при запуске:

   -verbose:class
   

Это покажет, откуда и каким загрузчиком загружался каждый класс.

4. Используй инструменты:
- jvisualvm (вкладка "Class Loader")
- jconsole
- плагин для IntelliJ: "Classloader Leak Prevention"


📌 А что такое child-first загрузчики?

По умолчанию Java использует parent-first стратегию: сначала спрашивает родителя, и только потом загружает сама. Но иногда нужно наоборот — особенно в системах с плагинами, чтобы изолировать версии зависимостей.

👉@BookJava

🧠 Как Java хранит boolean в памяти?

Сегодня я покажу вам, почему boolean в Java — это не просто true или false. А за этим простым типом скрывается интересный нюанс, особенно если ты задумываешься об экономии памяти.

В Java нет отдельного типа, который занимает всего 1 бит. Хотя логично было бы ожидать, что boolean — это один бит (true/false), на самом деле в памяти он занимает 1 байт (а иногда и больше, в зависимости от структуры объекта).

Пример:

public class Flags {
    boolean flag1;
    boolean flag2;
    boolean flag3;
}

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

📌 Причина:
JVM упрощает модель памяти ради производительности — доступ к байтам быстрее, чем к битам. Нет битовых сдвигов, масок и лишней логики.

💡 Что делать, если хочется сэкономить память?

Используй BitSet:

BitSet flags = new BitSet(3);
flags.set(0, true);

Это уже реальная битовая структура. Отличный выбор, если у тебя десятки или сотни логических флагов.

А ты знал об этом нюансе хранения boolean? Пиши в комментариях, сталкивался ли с перерасходом памяти из-за простых типов.

👉@BookJava

🔍 Почему Optional — это не замена null везде и всегда

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

Многие разработчики, особенно начинающие, начинают использовать Optional везде, где может быть null, думая, что это автоматически делает код "безопасным". Но так ли это?

📌 Ключевая идея Optional — сигнализировать о возможном отсутствии значения в результате вызова метода.
А не заменять все поля и параметры на Optional.

Примеры плохой практики:

public class User {
    private Optional<String> name; // ❌ Не нужно так делать
}

Почему это плохо:

- Увеличивается сложность сериализации (особенно с Jackson, GSON).
- Не соответствует архитектурной задумке: Optional — это не контейнер для полей.
- Проблемы с JPA (Hibernate не дружит с Optional-полями).
- Понижается читаемость кода.

💡 Лучше использовать Optional вот так:

public Optional<User> findUserById(Long id) {
    // Возвращаем Optional, потому что пользователь может не существовать
}

То есть Optional — это про контракт на метод, а не про хранение данных.

Если кратко:
- ✅ Используй Optional в сигнатурах методов, когда результат может отсутствовать.
- ❌ Не используй Optional в полях и параметрах конструктора.

А ты как используешь Optional в проектах? Был ли опыт с его неправильным применением? Пиши в комментах👇

👉@BookJava

🧠 @Value в Spring — это ловушка, если вы используете списки или map'ы

Многие знают, что можно заинжектить список строк из application.yml вот так:

app:
  langs:
    - en
    - fr
    - de

@Value("${app.langs}")
private List<String> langs;

Но знаете, что вы получите?

⚠️ ОШИБКУ. @Value не умеет парсить YAML-массивы. Он ожидает строку, и даже с CSV-строкой (en,fr,de) — всё не так очевидно: Spring не применяет ConversionService для списков.

📌 Решение — использовать @ConfigurationProperties:

app:
  langs:
    - en
    - fr
    - de

@ConfigurationProperties(prefix = "app")
@Component
public class AppProps {
    private List<String> langs;
    // геттеры/сеттеры
}

💡 Профит:
- работает с List, Map, вложенными объектами;
- валидация через @Validated и @NotEmpty;
- легко покрыть тестами;
- меньше магии.

⚠️ @Value хорош для простых скаляров. Всё остальное — через @ConfigurationProperties.

👉@BookJava

🧠 @Value vs @ConfigurationProperties — кого выбрать?

Часто вижу, как даже опытные разработчики по привычке используют @Value для инъекции конфигурации:

@Value("${app.timeout}")
private Duration timeout;

⚠️ Но с ростом приложения @Value становится хрупким и неудобным.

📌 Лучший подход — использовать @ConfigurationProperties:

@ConfigurationProperties(prefix = "app")
public record AppProperties(Duration timeout, String apiKey) {}

@Bean
@ConfigurationPropertiesBinding
public AppProperties appProperties() {
    return new AppProperties();
}

✅ Преимущества @ConfigurationProperties:
- 💡 Группирует настройки логически
- 🔍 Работает с валидацией (@Validated, @NotNull, и т.д.)
- 📚 Отлично поддерживается IDE (автокомплит, рефакторинг)
- 🔧 Удобно тестировать и мокать

🆕 Начиная с Spring Boot 2.2+, можно использовать record-классы и просто зарегистрировать бин через @EnableConfigurationProperties:

@Configuration
@EnableConfigurationProperties(AppProperties.class)
public class AppConfig {}

💬 Так что, если у вас в проекте до сих пор десятки @Value — самое время навести порядок.

👉@BookJava

GRASP: почему настоящая архитектура начинается не с SOLID

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

https://habr.com/ru/articles/900140/

👉@BookJava

Остался всего 1 день, чтобы прокачать асинхронный код на Scala Future 📢

15 апреля в 18:30 пройдёт открытый вебинар с Валентином Шилиным — старшим программистом и аналитиком данных Deutsche Telekom IT GmbH, экспертом по большим данным и преподавателем курсов по Scala и Apache Spark. Он расскажет:

— как избегать типичных ошибок (блокировки и потерю контекста)
— как комбинировать асинхронные операции (Future.sequence, traverse, for-comprehensions)
— как ускорить и упростить написание кода на Scala

❗️ Если вы хотите перейти с Java на Scala или уже используете Play Framework, Akka или Spark — на вебинаре вы узнаете, как грамотно писать асинхронный код и устранять «подводные камни».

Каждый участник:
— сможет задать вопросы эксперту
— получит скидку на полный курс по Scala-разработке

👉 Не упустите шанс перейти на новый уровень — регистрируйтесь, остался 1 день

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

🧠 Частая ловушка при работе с @Transactional в Spring

Сейчас покажу вам один распространённый анти-паттерн, который легко пропустить — вызов транзакционного метода внутри того же класса.

📌 Пример:

@Service
public class UserService {

    @Transactional
    public void registerUser(UserDto dto) {
        saveUser(dto);
    }

    @Transactional
    public void saveUser(UserDto dto) {
        // сохранение пользователя
    }
}

💥 Проблема:
Spring не применит транзакцию к saveUser(), потому что вызов происходит внутри одного и того же бина — минуя прокси.

Spring AOP работает через прокси, и @Transactional "срабатывает", только если метод вызывается извне, через прокси-объект.

⚠️ Это может привести к очень странным багам: вы думаете, что транзакция есть, а её нет.

💡 Как исправить:

1. Вынести метод в отдельный бин:

@Service
public class UserSaver {
    @Transactional
    public void save(UserDto dto) {
        // сохраняем
    }
}

@Service
public class UserService {
    private final UserSaver saver;

    public UserService(UserSaver saver) {
        this.saver = saver;
    }

    public void registerUser(UserDto dto) {
        saver.save(dto);
    }
}

2. Или использовать TransactionTemplate вручную.

✅ Всегда проверяйте, как вызываются методы с @Transactional. Особенно при рефакторинге!

👉@BookJava

❓ Разработчики, интересуетесь стримингом, хайлоадом и видеотехнологиями?

⏰ 22 апреля на митапе VK Видео техлиды и топ-менеджеры расскажут, как, например, устанавливают CDN.

Если вы бэкендер, мобильный разработчик или работаете с ML — будет много полезных кейсов из продакшена и возможность задать вопросы тем, кто строит крупнейшую видеоплатформу.

🎯 Узнаете, как устроена архитектура VK Видео, как выстроены команды и какие задачи сейчас в приоритете.

👉Загляните под капот VK Видео

🧠 Как ускорить cold start Spring Boot приложения

Как можно сократить время старта Spring Boot 3+ приложения — без GraalVM и без магии.

📌 Используем флаг:

-Dspring.context.cache.applicationContext=true

💡 Что это такое?
Это встроенный механизм кэширования ApplicationContext, появившийся в Spring Boot 3.2.

Он сохраняет результат построения контекста и позволяет повторно использовать его между запусками, особенно в тестах и development-сценариях.

⚙️ Как работает:
- При первом запуске контекст билдится как обычно.
- Затем сериализуется и сохраняется на диск.
- При следующем запуске он подгружается из кеша (если не изменился), что даёт ускорение в 2-3 раза и больше.

🚀 Отлично подходит для:
- Тестов (@SpringBootTest);
- Dev tools и локального запуска;
- Разработки больших монолитов.

⚠️ Не влияет на продакшн (там кеш не используется по умолчанию)
⚠️ Не поддерживает все конфигурации (например, динамические настройки могут инвалидировать кеш)

Простой флаг — а экономит кучу времени каждый день.

👉@BookJava

🧠 ThreadLocal — скрытая угроза утечек памяти

ThreadLocal — удобный способ хранить данные, привязанные к потоку. Например, для SimpleDateFormat или текущего пользователя в рамках запроса. Но с ним легко получить утечку памяти, особенно в thread pool'ах.

📌 Почему?
ThreadLocal-хранилище (Thread.threadLocals) живёт столько же, сколько поток. А потоки из пулов живут долго. Если ты забыл вызвать remove() — данные останутся в памяти навсегда.

Пример:

private static final ThreadLocal<UserContext> context = ThreadLocal.withInitial(UserContext::new);

public void handleRequest() {
    try {
        context.set(new UserContext("user123"));
        // работа с контекстом
    } finally {
        context.remove(); // ОБЯЗАТЕЛЬНО!
    }
}

⚠️ Что пойдёт не так без remove()?

- Поток из пула закончит обрабатывать запрос, но UserContext останется висеть в ThreadLocalMap этого потока.
- Если UserContext содержит ссылки на другие объекты (например, HttpSession, EntityManager и т.д.) — вся эта цепочка не будет GC-шиться.
- И так накапливается утечка.

💡 Советы:

- Всегда вызывай remove() в finally.
- Для Spring можно использовать RequestScope или @ControllerAdvice вместо ThreadLocal.
- Проверяй код сторонних библиотек, если они используют ThreadLocal, особенно в фильтрах и интерсепторах.

👉@BookJava

❓Сталкиваетесь с задачами, когда вам нужно выбрать лучший алгоритм, но не понимаете, как анализировать их сложность? Ваш код может быть медленным или неэффективным, и вы не знаете, как это исправить?

📗На открытом вебинаре 21 апреля в 20:00 мск вы освоите важные инструменты для анализа сложности алгоритмов, улучшите свой навык решения алгоритмических задач и на примере простых алгоритмов сортировки и увидите разницу при применении алгоритмов разной степени сложности.

➡️Регистрируйтесь прямо сейчас и получите скидку на большое обучение «C# Developer» по промокоду SHARP_SPEC_4: https://vk.cc/cKRCrB

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

💡 Ленивая инициализация бинов в Spring Boot — мощный инструмент ускорения старта

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

📌 Как ускорить старт и снизить потребление памяти? — Lazy Init!

✅ Глобально:

spring:
  main:
    lazy-initialization: true

Все бины станут ленивыми — создадутся только при первом обращении. Это может сократить старт приложения на 30-60%!

✅ Локально (избирательно):

@Component
@Lazy
public class HeavyBean {
    public HeavyBean() {
        System.out.println("HeavyBean init...");
    }
}

Или через @Lazy на зависимостях:

@Service
public class MyService {
    public MyService(@Lazy HeavyBean heavyBean) {
        this.heavyBean = heavyBean;
    }
}

🧠 Когда использовать:

- В dev-окружении — чтобы ускорить локальный dev cycle.
- В CLI/Batch-приложениях, где используется 1-2 бина.
- Когда есть тяжёлые бины, не нужные на старте (например, интеграции, большие клиенты и т.п.).

⚠️ Осторожно:

- Если забыть @Lazy на зависимостях, Spring всё равно создаст бин.
- Некоторые бины должны быть загружены сразу (например, @Scheduled, @EventListener), иначе они не сработают.

👉@BookJava