🐸 Библиотека джависта

#DevLife

🧩 final vs finally vs finalize()

Казалось бы, три похожих ключевых слова → final, finally, finalize(). А смысл принципиально разный. Давайте разберёмся.

🔹 final

Модификатор, который делает сущность неизменяемой:

▪️ final переменная → нельзя переприсвоить.
▪️ final метод → нельзя переопределить.
▪️ final класс → нельзя наследовать.

Используется для обеспечения immutability и контрактов в коде.

🔹 finally

Блок в try-catch, который выполняется всегда (даже если выброшено исключение).

Гарантирует освобождение ресурсов:

try {
FileReader reader = new FileReader("data.txt");
} catch (IOException e) {
e.printStackTrace();
} finally {
System.out.println("Закрываем ресурсы");
}

🔹 finalize()

Метод класса Object, вызываемый GC перед удалением объекта. Используется редко, считается устаревшим (deprecated с Java 9, удалён в Java 18).

Минус: непредсказуемое время вызова.

Современная альтернатива: try-with-resources или явная очистка.

💡 Вывод

final → контроль изменяемости.
finally → контроль завершения.
finalize() → контроль очистки (но не используйте).

🐸 Библиотека джависта

#CoreJava

Поставиллайк

🐸 Библиотека джависта

#DevLife

🐸 Библиотека джависта

#DevLife

🎮 DevTools на каждый день

Тут собраны самые популярные и эффективные инструменты для разных направлений: IDE, ИИ, безопасность и многое другое.

💬 Какие инструменты используете в повседневной работе?

🐸 Библиотека джависта

#Enterprise

⚡️ Optional: must-have или лишний шум?

✔️ "За" Optional
— Убирает null-ы из кода
— Более читаемая и безопасная API
— Стандартный инструмент, без сторонних либ

❌ "Против" Optional
— Часто приводит к избыточным обёрткам
— Усложняет код при массовом использовании
— Всё равно не решает проблему null на 100%

💬 В комментах напишите, где используете Optional в проде.

🐸 Библиотека джависта

#DevLife

🔍 Просто о сложном: Spring Boot

Spring Boot — это не «новый фреймворк», а надстройка над Spring, которая убирает рутину и ускоряет разработку.

В обычном Spring нужно было вручную конфигурировать всё: от DataSource до DispatcherServlet. В Boot это делается автоматически через автоконфигурацию.

🔹 Как работает автоконфигурация

Spring Boot сканирует зависимости и classpath, а затем подключает нужные бины:

— Если у вас есть spring-boot-starter-data-jpa, Boot автоматически создаст EntityManagerFactory, DataSource, транзакционный менеджер.

— Если добавлен spring-boot-starter-web, он поднимет встроенный Tomcat/Jetty и зарегистрирует контроллеры. И так далее.

Магия кроется в аннотации @EnableAutoConfiguration (включается через @SpringBootApplication). Она загружает META-INF/spring.factories → список классов-конфигов → каждый проверяет условия @ConditionalOnClass, @ConditionalOnMissingBean и решает: активироваться или нет.

💡 Почему это работает так гладко

Потому что в Boot сотни готовых конфигураций «на все случаи жизни».

Фактически, это огромная библиотека «если увидишь X — настрой Y».

👀 Подводный слой магии

— Черный ящик

Легко забыть, что именно сконфигурировал Boot. Иногда приходится «копать» в автоконфигурацию, чтобы понять, какой бин реально используется.

— Избыточные зависимости

Подключив Starter, можно случайно притащить половину экосистемы Spring. Это увеличивает время старта и усложняет дебаг.

— Конфликт настроек

Собственная конфигурация может пересечься с автоконфигурацией.

⚡️ Хорошая практика

— Не доверяйте «чёрному ящику»: при старте приложения смотрите Spring Boot Actuator и логи автоконфигурации.

— Знайте про --debug при старте: он показывает, какие автоконфигурации включены или отключены.

— В продакшене лучше контролировать, какие именно стартеры вы тянете. Иногда spring-boot-starter-web приносит в проект в три раза больше, чем реально нужно.

🎯 Итог

Spring Boot — это ускоритель, но не магия. Его сила в автоконфигурациях, а слабость в том, что легко потерять контроль.

Понимание того, как работает @EnableAutoConfiguration и условия @Conditional, отличает разработчика, который «просто пишет на Boot», от того, кто реально управляет приложением.

🐸 Библиотека джависта

#CoreJava