Библиотека Java разработчика

📌 Java Collections 📲 Мы в MAX 👉@BookJava

🧠 Spring Boot: ленивые зависимости через ObjectProvider Иногда сервису не нужно всегда инжектить другую зависимость при старте — только иногда по ходу работы. Но @Autowired всё равно тянет её сразу, даже если она вам пока не нужна. Это бьёт по времени старта и может вызвать циклические зависимости. 💡 Решение: использовать ObjectProvider<T>. Пример:

@Service
public class NotificationService {

    private final ObjectProvider<EmailSender> emailSenderProvider;

    public NotificationService(ObjectProvider<EmailSender> emailSenderProvider) {
        this.emailSenderProvider = emailSenderProvider;
    }

    public void sendEmailIfEnabled(String to, String body) {
        if (featureEnabled()) {
            EmailSender sender = emailSenderProvider.getIfAvailable();
            if (sender != null) {
                sender.send(to, body);
            }
        }
    }
}

📌 ObjectProvider: ▫️не создаёт бин сразу — ленивый доступ; ▫️ позволяет проверить наличие бина (getIfAvailable() / ifAvailable(...)); ▫️можно использовать stream() — для коллекций бинов. ⚠️ Это не альтернатива DI. Это способ контролировать создание и использование бинов вручную, когда это действительно нужно. 📈 Отлично помогает: ▫️при борьбе с циклическими зависимостями; ▫️для optional-бинов; ▫️чтобы ускорить старт приложения. 📲 Мы в MAX 👉@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 (если нужен контроль и очереди) 📲 Мы в MAX 👉@BookJava

🔴 Завтра тестовое собеседование с Java-разработчиком 2 сентября(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика. Как это будет: 📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Сергею Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

🔧 Maven vs. Gradle: что выбрать разработчику? Когда речь заходит о сборке Java-проектов, выбор обычно падает на два главных инструмента: Maven и Gradle. Оба давно стали стандартом индустрии, но каждый имеет свои особенности. Разберёмся, что выбрать 👇 ☕ Maven — проверенная классика ✅ Строгая структура: легче читать и сопровождать ✅ Надёжность и предсказуемость сборки ✅ Большое комьюнити и множество плагинов ⚠️ XML-конфигурация громоздкая ⚠️ Медленнее по сравнению с Gradle ⚡ Gradle — гибкость и скорость ✅ Поддержка Kotlin и Groovy DSL ✅ Инкрементальные сборки и кэширование → быстрее ✅ Более гибкий подход к настройке ⚠️ Порог входа выше ⚠️ Иногда сложно отлаживать конфигурацию 💡 Вывод: * 🔹 Выбирай Maven, если важны стабильность, простота и читаемость. * 🔹 Выбирай Gradle, если хочешь максимум производительности и гибкости. 🎯 В крупных проектах Gradle становится всё популярнее, особенно при использовании Kotlin. Но в enterprise-среде Maven по-прежнему правит бал. 📲 Мы в MAX 👉@BookJava

🧠 Трюк с @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+ обязательно проверьте, что нужные конфигурации действительно подхватываются. Особенно, если раньше они подключались "магически". 📲 Мы в MAX 👉@BookJava

🧠 Неочевидный performance-трюк с @Transactional(readOnly = true) Многие используют @Transactional(readOnly = true) просто по инерции. Но вы знали, что в Spring это влияет не только на семантику, но и на производительность? 📌 Что делает readOnly = true: * Подсказывает Hibernate, что внутри транзакции не будет изменений сущностей. * Это позволяет избежать затрат на грязную проверку (dirty checking). * Не создаётся snapshot состояний сущностей → меньше памяти и операций. 💡 Пример:

@Transactional(readOnly = true)
public List<User> findActiveUsers() {
    return userRepository.findByActiveTrue();
}

⚠️ А теперь важно: если вы случайно измените сущность в таком методе, Hibernate проигнорирует изменения — потому что readOnly намекает: "не трогай". 📉 В реальном приложении с большим количеством запросов к БД, особенно читающих, такой подход даёт ощутимый буст — меньше нагрузки на ORM, меньше GC, быстрее ответы. 📌 Где применять: * Методы только для чтения. * REST-эндпоинты GET. * Сервис-методы, возвращающие DTO и не модифицирующие Entity. ⚠️ Где не надо: * Методы с lazy-loading и последующими модификациями. * Там, где возможно случайное изменение Entity (например, через mapper'ы). 👉 Используйте @Transactional(readOnly = true) не как декор, а как инструмент для оптимизации. 📲 Мы в MAX 👉@BookJava

🧠 Spring Boot: правильно логируем @ExceptionHandler Сейчас покажу простой, но часто упускаемый момент при обработке ошибок в Spring Boot. Если у вас есть глобальный @ExceptionHandler, убедитесь, что вы не теряете stacktrace при логировании. ❌ Плохо:

@ExceptionHandler(MyException.class)
public ResponseEntity<String> handle(MyException ex) {
    log.error("MyException occurred: {}", ex.getMessage()); // stacktrace теряется!
    return ResponseEntity.status(500).body("Error");
}

✅ Хорошо:

@ExceptionHandler(MyException.class)
public ResponseEntity<String> handle(MyException ex) {
    log.error("MyException occurred", ex); // stacktrace будет видно в логе
    return ResponseEntity.status(500).body("Error");
}

📌 log.error(String, Throwable) — правильный способ логировать исключения. Это позволяет: * Сохранять stacktrace для дебага; * Не терять вложенные причины (getCause()); * Работать с лог-агрегаторами (ELK, Grafana, etc). 💡 Если вы используете Slf4j и формат log.error("message: {}", ex.getMessage()), вы теряете почти всю полезную информацию об ошибке. ⚠️ И не забывайте: глобальные хендлеры — это хорошо, но не глушите все ошибки без разбора. Лучше создавать разные @ExceptionHandler под каждую категорию исключений. 📲 Мы в MAX 👉@BookJava

🧠 Spring Boot: как НЕ попасть в ловушку с @Scheduled и многопоточностью Когда используете @Scheduled для периодических задач в Spring Boot, важно понимать: по умолчанию все задачи выполняются в одном потоке.

@Scheduled(fixedRate = 5000)
public void syncData() {
    // долгая операция
}

📌 Если таких задач несколько или они работают долго — остальные ждут. Это создаёт бутылочное горлышко и приводит к неожиданным задержкам. 💡 Решение: настроить кастомный executor:

@Configuration
@EnableScheduling
public class SchedulerConfig implements SchedulingConfigurer {

    @Override
    public void configureTasks(ScheduledTaskRegistrar registrar) {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(5); // количество параллельных задач
        scheduler.setThreadNamePrefix("scheduled-task-");
        scheduler.initialize();
        registrar.setTaskScheduler(scheduler);
    }
}

Теперь все @Scheduled - методы будут использовать пул потоков, а не один. ⚠️ Не забывайте: если задача критична к ресурсам или зависит от внешних сервисов — добавьте внутреннюю защиту от повторного выполнения, например, с помощью Redis lock или базы. ✅ Подключение пула — must-have для production-проектов, где @Scheduled выполняет реальные задачи, а не просто println. 📲 Мы в MAX 👉@BookJava

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. https://max.ru/tipsysdmin Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/channel_i_linux Системный администратор https://max.ru/channel_devopslib DevOps, SRE, Sysadmin https://max.ru/channel_devops_star DevOps Star (Звезда Девопса) Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхак Английский с нуля 🇬🇧 https://max.ru/UchuEnglish 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С https://max.ru/channel_DevLab1C 1С:Предприятие 8 Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика https://max.ru/channel_cpp_geek C++ geek Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Rust📌 https://max.ru/channel_rust_lib Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика https://max.ru/channel_java_geek Java Geek GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии в IT📌 https://max.ru/progjob https://max.ru/channel_rabotait Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Городские📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП https://max.ru/channel_krasnodar_novosty Краснодар Новости https://max.ru/channel_novosibirsk_novosti Новосибирск https://max.ru/channel_samara_novosti Новости Самары https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга https://max.ru/channel_kazan_novosti Новости Казани https://max.ru/channel_omsk_novosti Новости Омска https://max.ru/channel_moskva_24 Москва 24

💡 Не делай этого в @PostConstruct — особенно в проде Сейчас расскажу, почему инициализировать важную бизнес-логику в @PostConstruct — плохая идея. Типичный пример:

@Component
public class CacheLoader {

    private final SomeService service;

    public CacheLoader(SomeService service) {
        this.service = service;
    }

    @PostConstruct
    public void init() {
        service.loadDataIntoCache(); // ⚠️ обращение к БД
    }
}

🧨 Проблема: @PostConstruct вызывается до того, как приложение полностью поднялось. Если внутри будет ошибка (например, БД недоступна) — приложение может упасть, или что хуже — запуститься в полурабочем состоянии. 📌 Кроме того: * ❌ Нет контроля над порядком выполнения таких методов; * ❌ Нельзя легко переиспользовать эту логику (например, вручную перезагрузить кеш); * ❌ В тестах или dev-среде — такие вызовы часто мешают. ✅ Современный подход — использовать ApplicationListener:

@Component
public class CacheLoader implements ApplicationListener<ApplicationReadyEvent> {

    private final SomeService service;

    @Override
    public void onApplicationEvent(ApplicationReadyEvent event) {
        service.loadDataIntoCache(); // 👍 вызывается только после старта
    }
}

📌 Альтернатива — аннотация @EventListener:

@EventListener(ApplicationReadyEvent.class)
public void onReady() {
    // безопасно загружаем данные
}

📦 В Spring Boot это нативный и рекомендованный способ выполнения кода после старта. 🧠 Резюме: 🔹 @PostConstruct — только для простой инициализации бинов. 🔹 Бизнес-логику и I/O — в @EventListener(ApplicationReadyEvent.class). 📲 Мы в MAX 👉@BookJava

🧠 JVM-разработчики, стягиваемся в Москву 29 августа В последнюю субботу лета бэкенд- и JVM-комьюнити соберется на JVM Day, который устраивает Т-Банк. Ждут всех разработчиков, архитекторов и тимлидов, которые работают с Java, Kotlin и Scala. В программе: – Андрей Кулешов расскажет о том, что изменилось в мире JVM за год. – Сергей Петрелевич разберет Mechanical Sympathy. – Александр Ланцов покажет, какие модели конкурентности актуальны после появления Loom. – Антон Курако объяснит, почему красивые показатели бенчмарков могут вводить в заблуждение. А после докладов во дворе штаб-квартиры Т-Банка пройдут: – Игры на Sega и ИТ-Квиз. – PowerPoint Party и открытый микрофон с историями ошибок. – Диджей-сет на виниле под открытым небом. Места ограничены, регистрироваться тут. Пишите в комментариях, если идете на конфу. 📲 Мы в MAX 👉@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. 📲 Мы в MAX 👉@BookJava

👩‍💻 Работа с Kafka через библиотеку Kafka Clients Приглашаем на открытый урок. 🗓 26 августа в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «Java разработчик. Продвинутый уровень». Kafka Clients это нижний уровень для работы с Kafka из Java. Все более высокоуровневые библиотеки основаны на нем. Данный открытый урок проходит в рамках курса Java разработчик. Продвинутый уровень. О чем поговорим: ✔️ Чтение и отправка сообщений в Kafka ✔️ Управление топиками ✔️ Разные форматы: текст, JSON, Avro ✔️ Использование транзакций 🔗 Ссылка на регистрацию: https://vk.cc/d0zMZ5 Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🧠 Нюанс с Optional.map() и методами, возвращающими Optional Многие Java-разработчики на автомате пишут что-то вроде:

Optional<User> user = findUserById(id); // возвращает Optional<User>

Optional<String> email = user.map(User::getEmail); // getEmail тоже возвращает Optional<String>

⚠️ Проблема: map() в Optional не "разворачивает" вложенные Optional. В этом примере email будет типа Optional<Optional<String>>, что почти всегда нежелательно. 📌 Правильный способ — использовать flatMap():

Optional<String> email = user.flatMap(User::getEmail);

💡 flatMap() позволяет избежать "двойной обёртки", если метод внутри map() уже возвращает Optional. 🔁 Аналогичная ситуация с Stream.map() — если внутри map() вызывается метод, возвращающий Stream, то получится Stream<Stream<T>>, и опять же нужно использовать flatMap(). 🧪 Мини-памятка: * map() — когда метод возвращает обычный тип (T → R); * flatMap() — когда метод возвращает Optional или Stream (T → Optional<R> или T → Stream<R>). 📲 Мы в MAX 👉@BookJava

Почему ты получаешь отказ после "норм собеса"? Дело не в знаниях - ты просто не знаешь, что реально проверяют на собеседованиях Отсюда:  — непонимание, какие навыки надо качать, чтобы выйти на следующий грейд  — ощущение стагнации и отсутствие роста в скиллах  — долгое время на одной и той же зп Решение — знать, что от тебя ждёт интервьюер, и умение правильно донести свою мысль Для этого ребята из ШОРТКАТ (менторской программы для разработчиков) собрали в один файл ОТВЕТЫ НА 50 СЛОЖНЫХ ВОПРОСОВ с Java-собеседований 🔥 Они проанализировали более 100 мок-интервью и собрали внутри реальные вопросы + ответы сильного кандидата Забрать можно бесплатно (!) в боте — @shortcut_sh_bot Переходите по ссылке выше и забирайте файл, чтобы быстрее выйти на новый уровень ☝️ Реклама. О рекламодателе.

Java. Сортировки Java. Сортировка пузырьком. Java. О сортировке выбором. Java. Быстрая сортировка. Объяснение на пальцах) Java. Оценка сложности алгоритмов сортировки. Java. Сортировка слиянием. Java. Сортировка подсчетом. Java. Сортировка вставками. Java. Сортировка расческой. От пузырька до расчески. 📲 Мы в MAX 👉@BookJava

🧠 Как в Java сломать equals() и потерять данные в HashMap Сегодня покажу, как неочевидный баг в equals()/hashCode() может привести к потере данных при работе с HashMap. Допустим, у вас есть Entity:

public class User {
    private String id;
    private String name;

    // equals/hashCode только по id
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof User)) return false;
        User user = (User) o;
        return Objects.equals(id, user.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}

Вроде норм. Но теперь добавим такого юзера в HashMap, а потом... изменим его id:

User user = new User();
user.setId("1");
user.setName("Alice");

Map<User, String> map = new HashMap<>();
map.put(user, "value");

user.setId("2"); // ⚠️ ключ стал "невидимым"

System.out.println(map.get(user)); // null 😱

📌 Почему так происходит? HashMap ищет ключ по hashCode() → ищет бакет → сравнивает через equals(). А hashCode() уже другой, и объект "теряется". 💡 Совет: если вы используете объект как ключ в мапе или добавляете его в Set, не изменяйте его поля, участвующие в equals()/hashCode()! 📌 А как правильно? - Делайте такие поля final; - Или используйте неизменяемые типы (record); - Или не используйте такие объекты как ключи вовсе. Вот безопасный вариант с record:

public record User(String id, String name) {}

📲 Мы в MAX 👉@BookJava

💡Сегодня покажу крутую фишку для оптимизации чтения больших коллекций из базы через JPA. 📌 Проблема: Когда загружаем большую коллекцию через @OneToMany, Hibernate часто делает это лениво (LAZY), но при первом доступе — забирает всю коллекцию целиком. Это может привести к OutOfMemoryError или резкому проседанию производительности. 📌 Решение: использовать пагинацию (batch-size) или запрос коллекции порциями. Как настроить batch-size на уровне сущности:

@Entity
public class User {
    
    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    @BatchSize(size = 50)
    private List<Order> orders;
}

🧠 Теперь Hibernate будет загружать за раз по 50 элементов, а не всю коллекцию сразу! 📌 Или можно настроить глобально через application.properties:

spring.jpa.properties.hibernate.default_batch_fetch_size=50

⚠️ Важно: - @BatchSize работает только для LAZY-связей. - Это не пагинация в SQL, а оптимизация внутренних запросов Hibernate. - Если коллекция огромная (100k+ записей) — лучше делать явные paged запросы в репозитории. 💡Помните: без настройки batch-size Hibernate может сломать приложение под нагрузкой. Оптимизируйте загрузку коллекций заранее! 📲 Мы в MAX 👉@BookJava

Как работают instance initializer blocks. Пример с родительским и дочерним классами:

class Parent {
    int a = 5;

    {
        System.out.println("Parent instance initializer");
        a = 10;
    }

    Parent() {
        System.out.println("Parent constructor, a = " + a);
    }
}

class Child extends Parent {
    int b = 15;

    {
        System.out.println("Child instance initializer");
        b = 25;
    }

    Child() {
        System.out.println("Child constructor, b = " + b);
    }
}

public class Test {
    public static void main(String[] args) {
        Child child = new Child();
    }
}

Вывод программы:

Parent instance initializer
Parent constructor, a = 10
Child instance initializer
Child constructor, b = 25

Пошаговое выполнение: 1. Сначала загружается родительский класс Parent. 2. Выполняется: - Инициализация полей родителя (a = 5), - Потом instance initializer блока родителя (a = 10), - Потом конструктор родителя (Parent()). 3. Далее переходим к дочернему классу Child: - Инициализация полей дочернего класса (b = 15), - Потом instance initializer блока дочернего класса (b = 25), - Потом конструктор дочернего класса (Child()). Важный порядок действий: 1. Инициализация родителя → 2. Конструктор родителя → 3. Инициализация потомка → 4. Конструктор потомка. Блоки инициализации всегда выполняются до тела конструктора, но после вызова super(). 📲 Мы в MAX 👉@BookJava