Java Books

✔️ Java-совет, который спасает от тихих утечек ресурсов. Если работаете с BufferedReader, InputStream, OutputStream, FileReader, соединениями или другими ресурсами, которые нужно закрывать, используйте try-with-resources. Плохо:

BufferedReader reader = new BufferedReader(new FileReader("data.txt"));

String line;
while ((line = reader.readLine()) != null) {
    System.out.println(line);
}

reader.close();

На первый взгляд всё нормально. Но если внутри чтения файла вылетит исключение, reader.close() может не выполниться. В итоге останутся открытые file handles, stream’ы или соединения. Лучше так:

try (BufferedReader reader =
         new BufferedReader(new FileReader("data.txt"))) {

    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
}

try-with-resources автоматически вызовет close() даже при исключении. Почему это важно: * не нужен ручной finally * меньше boilerplate-кода * ниже риск утечек ресурсов * код проще читать * безопаснее работать с файлами, сетью и БД Правило простое: если объект реализует AutoCloseable или Closeable, почти всегда стоит использовать try-with-resources. Это одна из тех привычек, которые делают Java-код чище и надёжнее.

📌 Magic numbers в Java - мелкая привычка, которая потом превращает поддержку кода в археологию. Когда в коде встречается 86400, 7, 1.21 или 5000, компилятору всё равно. Человеку - нет. Через месяц уже приходится вспоминать, что это было: секунд в дне, дней сессии, НДС или задержка перед повторной попыткой. Плохой вариант выглядит так: if (sessionAgeSeconds > 86400 * 7) Формально код работает. Но смысл спрятан внутри чисел. Нормальный вариант: SECONDS_PER_DAY SESSION_DAYS VAT_RATE RETRY_DELAY_MS Теперь намерение видно прямо в месте вызова. Не нужно угадывать, почему именно 7, что означает 5000 и можно ли безопасно поменять значение. Это особенно важно в бизнес-логике, где числа редко бывают случайными. Лимиты, комиссии, таймауты, скидки, сроки жизни сессии, количество попыток - всё это правила продукта, а не просто цифры в коде. Хорошее правило простое: если число несёт смысл, дай ему имя. Исключения вроде 0, 1, индексов и простых счётчиков можно не трогать. Чистый код часто начинается не с архитектуры, а с таких скучных вещей: убрать загадочные числа и оставить будущему разработчику понятный контекст. #java #cleancode

N+1 в Spring Boot выглядит безобидно, пока прод не начинает молиться на базу данных. Классический сценарий: Вы грузите список заказов: orderRepository.findAll() А потом в цикле обращаетесь к order.getItems(). Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items. 100 заказов = 101 SQL-запрос. И вот здесь спасает @EntityGraph. Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу: @EntityGraph(attributePaths = {"items"}) В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу. Что получаем: - меньше SQL-запросов - меньше нагрузки на БД - чище код репозитория - без ручного JPQL - fetch-стратегия управляется точечно под конкретный кейс LAZY сам по себе не зло. Зло - когда вы не контролируете, где и как он срабатывает. @EntityGraph - один из самых простых способов держать N+1 под контролем в Spring Boot.

Твой код — в сердце мощного ИИ! 💚 Команда GigaChat зовёт на One Day Offer амбициозных Java-разработчиков, которые готовы создавать AI‑продукты уровня BigTech и стать частью крупнейшего AI-комьюнити. Если ты дружишь с Java (версии 8–25), ладишь со Spring и Hibernate, а PostgreSQL и ClickHouse для тебя — не просто слова, переходи по ссылке и занимай слот на One Day Offer. Встречаемся 23 мая — очень ждём именно тебя!

Spring Boot: уберите try/catch из контроллеров В Spring Boot не нужно размазывать обработку ошибок по каждому endpoint через бесконечные try/catch. Для этого есть @RestControllerAdvice. Идея простая: вы выносите обработку исключений в один глобальный класс, а контроллеры оставляете чистыми. Например:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<?> handleNotFound(ResourceNotFoundException ex) {
        return ResponseEntity
                .status(HttpStatus.NOT_FOUND)
                .body(new ErrorResponse("NOT_FOUND", ex.getMessage()));
    }

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<?> handleBadRequest(IllegalArgumentException ex) {
        return ResponseEntity
                .badRequest()
                .body(new ErrorResponse("BAD_REQUEST", ex.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<?> handleGeneric(Exception ex) {
        return ResponseEntity
                .status(HttpStatus.INTERNAL_SERVER_ERROR)
                .body(new ErrorResponse("INTERNAL_ERROR", "Something went wrong"));
    }
}

После этого контроллер может выглядеть спокойно:

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userService.findById(id);
}

Если пользователь не найден - сервис кидает ResourceNotFoundException, а Spring сам отправит нормальный 404. Что это даёт: • меньше мусора в контроллерах • единый формат ошибок • проще поддерживать API • легче логировать исключения • меньше копипасты в endpoint-ах Контроллер должен описывать сценарий запроса, а не превращаться в свалку обработки ошибок.

N+1 в Spring Boot выглядит безобидно, пока прод не начинает молиться на базу данных. Классический сценарий: Вы грузите список заказов: orderRepository.findAll() А потом в цикле обращаетесь к order.getItems(). Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items. 100 заказов = 101 SQL-запрос. И вот здесь спасает @EntityGraph. Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу: @EntityGraph(attributePaths = {"items"}) В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу. Что получаем: - меньше SQL-запросов - меньше нагрузки на БД - чище код репозитория - без ручного JPQL - fetch-стратегия управляется точечно под конкретный кейс LAZY сам по себе не зло. Зло - когда вы не контролируете, где и как он срабатывает. @EntityGraph - один из самых простых способов держать N+1 под контролем в Spring Boot.

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

Небольшой, но полезный совет для Spring Boot. Если у вас есть scheduled task, не стоит хардкодить интервал прямо в аннотации:

`@Scheduled(fixedRate = 5000)`

Лучше вынести значение в конфиг:

`@Scheduled(fixedRateString = "${task.interval}")`

А в application.properties указать:

`task.interval=5000`

Почему так лучше: • интервал можно менять без правки кода; • настройки проще различать для dev, staging и production; • меньше магических чисел в бизнес-логике; • конфигурация становится прозрачнее. Мелочь, но именно из таких мелочей и складывается нормальная поддерживаемость Spring Boot-проекта.

⚡️ CORS в Spring Boot: не лечите это костылями на фронте Если frontend и backend живут на разных доменах или портах, браузер начнет резать запросы по CORS. Это не баг Spring Boot и не проблема React. Это нормальный механизм безопасности браузера. Правильный способ - настроить CORS на стороне backend. В Spring Boot это можно сделать глобально через WebMvcConfigurer: указать маршруты, разрешенные origins, HTTP-методы, заголовки и работу с credentials. Главное - не ставить бездумно * везде подряд, особенно если используете cookies, токены или allowCredentials(true). В проде лучше явно перечислять доверенные домены, например frontend-домен приложения. Такой подход дает централизованный контроль: вы один раз задаете политику CORS и не размазываете настройки по каждому контроллеру. Для Java backend-разработчика это базовая, но важная вещь: CORS должен быть частью архитектуры API, а не случайной правкой перед деплоем.

👣 На Stepik обновили курс «Rust: полный курс разработчика. С нуля до профи» Представьте: через три месяца вы открываете чужой Rust-код и читаете его как книгу. Arc<Mutex<T>> не вызывает панику. impl Future не пугает. Вы точно знаете, почему компилятор ругается и как это починить за 10 секунд. Это не фантазия. Это результат 50 уроков, в которых каждая концепция объясняется через код и закрепляется практикой. Ownership, traits, generics, async, unsafe - всё, что казалось магией, станет рабочим инструментом. А бонусом - портфолио проектов: от CLI-утилит до REST API и WebAssembly. Вы и так знаете, что Rust - ваш следующий язык. Этот курс просто сделает это реальностью. Сегодня - 55% процентов от цены, торопись: https://stepik.org/a/269250/

⚡️ Перестаём писать методы с 7+ параметрами Если сигнатура выглядит как: createUser(firstName, lastName, email, phone, address, city, country) Это уже сигнал, что модель данных развалилась. Проблема не только в читаемости. Такие методы сложнее поддерживать, расширять и тестировать. Любое изменение ломает сигнатуру и тянет за собой каскад правок. Нормальный вариант - собрать связанные данные в объект: UserInfo userInfo Получаем: - чище API - проще добавлять поля - меньше ошибок при передаче параметров - код начинает отражать доменную модель, а не список строк Это базовый приём, но именно на нём чаще всего экономят, а потом платят сложностью.

🚀 Ты всё ещё называешь обёртку над ChatGPT «AI-продуктом»? Пока ты пишешь промпты - рынок уже ушёл дальше. Сейчас выигрывают не те, кто умеет красиво формулировать запросы, а те, кто строит агентные системы: - принимают решения сами - ходят в API - работают с Postgres и Redis - управляют браузером через Playwright - доводят задачи до результата без человека И вот правда, о которой мало говорят: 90% таких систем умирают между ноутбуком и продом. Работает локально. Ломается в реальности. Нет архитектуры. Нет устойчивости. Нет деплоя. AI Agents Engineering - курс со Stepik, который закрывает этот разрыв. - LangGraph, AutoGen, Computer Use - архитектура агентов, а не «скрипты на коленке» - LLMOps, логирование, стабильность - деплой в Docker и работа в проде 8 модулей, 120+ шагов, всё через практику. На выходе не «сертификат ради галочки», а: - рабочий production-агент - понимание, как строить такие системы с нуля - навыки, за которые уже платят Сейчас самое окно входа. Через полгода это станет базой, а не преимуществом. Скидка 55% действует ещё 48 часов: https://stepik.org/a/276971/

🚀 GigaChat 3.1 Ultra и GigaChat 3.1 Lightning в опенсорс под MIT лицензией! Обе модели • Обучены с нуля — без инициализации зарубежными весами • MoE + MTP + MLA • Совместимы с HuggingFace, llama.cpp / vLLM / SGLang Код и веса уже на платформе GitVerse. Это не просто релиз весов, а результат большой инженерной работы над качеством, alignment и стабильностью модели. В блоге команда поделилась результатами и своими наработками. В релизе: высокие результаты на аренах, улучшенный function calling, решённая проблема циклов, DPO в нативном FP8, найденный и зарепорченный баг в SGLang при dp > 1.

Spring Boot может уронить API из-за одного лишнего поля в JSON Классика: приходит запрос с дополнительным полем, которого нет в DTO и ты ловишь UnrecognizedPropertyException. Клиент добавил поле, ты не обновил модель - всё падает. Решение в одну строку:

@JsonIgnoreProperties(ignoreUnknown = true)
public class UserDTO {
    private String name;
    private int age;
}

Теперь Jackson просто игнорирует лишние поля вместо того, чтобы ломать приложение. Полезно, когда API живёт долго, клиенты обновляются быстрее бэка, а ломать совместимость нельзя.

📌 Нашли 15 сайтов с миллионами бесплатных книг Это не просто подборка, а реально огромные библиотеки от художки до научных статей, диссертаций и учебников. И главное базы постоянно обновляются • planetebook.com • oceanofpdf.com • freecomputerbooks.com • zlibrary.to • bookboon.com • gutenberg.org • manybooks.net • pdfdrive.com • digilibraries.com • openlibrary.org • standardebooks.org • librivox.org • getfreeebooks.com • authorama.com Если читаешь и прокачиваешься сохрани, пригодится

🚀 GigaChat 3.1 Ultra и GigaChat 3.1 Lightning в опенсорс под MIT лицензией! Обе модели • Обучены с нуля — без инициализации зарубежными весами • MoE + MTP + MLA • Совместимы с HuggingFace, llama.cpp / vLLM / SGLang Код и веса уже на платформе GitVerse. Это не просто релиз весов, а результат большой инженерной работы над качеством, alignment и стабильностью модели. В блоге команда поделилась результатами и своими наработками. В релизе: высокие результаты на аренах, улучшенный function calling, решённая проблема циклов, DPO в нативном FP8, найденный и зарепорченный баг в SGLang при dp > 1.

⚡️ Java лайфхак: не убивай производительность боксингом Многие даже не замечают, как теряют скорость из-за автoboxing в Stream API. ❌ Плохо (создаются объекты Integer): Stream boxed = Stream.of(1, 2, 3, 4, 5); int sum = boxed.reduce(0, Integer::sum); Каждое число → объект → лишняя память + нагрузка на GC ✅ Хорошо (работа с примитивами): int sum = IntStream.of(1, 2, 3, 4, 5).sum(); Без лишних объектов. Быстрее. Чище. Запомни: - IntStream → для int - LongStream → для long - DoubleStream → для double Если работаешь с числами — всегда используй primitive streams. Это мелочь, которая на больших данных превращается в реальную экономию ресурсов. Сохрани, чтобы не писать медленный код.

🚀 Java - regex без боли Нашли интересную библиотеку - Sift. Она заменяет весь этот ад с регулярками на нормальный fluent API. Теперь вместо нечитаемых строк вида: ^[0-9a-fA-F]{6}$ Пишешь код, который реально понимаешь: .char('#') .then() .exactly(6) .hexDigits() 📌 Что это дает: - Читаемый и понятный код - Меньше ошибок в regex - Быстрее разработка и поддержка По сути — это как “переводчик” с языка регулярных выражений на человеческий Java-код. Если когда-нибудь ломал голову над regex -это прям must-have. #Java #JavaDev

🔥 Лучшие БЕСПЛАТНЫЕ ресурсы по Linux в 2026 году 1. Linux Foundation Training https://training.linuxfoundation.org/training/introduction-to-linux/ 2. Linux Journey https://linuxjourney.com 3. Ubuntu Tutorials https://ubuntu.com/tutorials 4. Red Hat Training Resources https://developers.redhat.com/learn 5. Документация GNU https://gnu.org/manual 6. OverTheWire Bandit (Linux-варгеймы) https://overthewire.org/wargames 7. Книга The Linux Command Line https://linuxcommand.org/tlcl.php 8. MIT Missing Semester (Linux и CLI) https://missing.csail.mit.edu 9. Туториалы по Linux от DigitalOcean https://digitalocean.com/community/tutorials 10. Linux From Scratch https://linuxfromscratch.org 11. Arch Linux Wiki https://wiki.archlinux.org 12. Курс по Linux от freeCodeCamp https://freecodecamp.org/news/tag/linux 13. Linux Survival (интерактивное обучение) https://linuxsurvival.com 14. NDG Linux Essentials https://netacad.com/courses/os-it/ndg-linux-essentials 15. Bash Guide (руководство по Bash) https://tldp.org/LDP/Bash-Beginners-Guide/html

Приглашаем бэкенд-разработчиков на Week Offer Backend* Такой формат позволяет пройти секции и финалы за неделю и сразу получить офер. Зарегистрироваться можно до 8 апреля, а сам ивент пройдёт с 11 по 17 апреля, онлайн. Кого мы ищем: 🟢 Бэкенд-разработчиков c опытом работы от 4 лет на C++, Python, Java/Kotlin, Go**. 🟢 Стажёров-разработчиков c навыком кодинга на C++, Python, Java, Kotlin, Go** и базой по алгоритмам и структурам данных. 🔶 Все подробности, регистрация и материалы для подготовки доступны на сайте: https://yandex.ru/project/events/wo_backend_0426 Приходите создавать полезные продукты для миллионов пользователей!