Java

⚡️ Бинарный поиск, который вы выучили, скорее всего, был неправильным. Джон Бентли опубликовал реализацию бинарного поиска в *Programming Pearls* после того, как доказал её корректность и протестировал. Баг прожил почти 20 лет. Позже Джошуа Блох нашёл точно такую же ошибку в реализации бинарного поиска, которую сам написал для JDK. Исследование 1988 года показало: корректный бинарный поиск был только в 5 из 20 учебников. Ошибка проявляется только на массивах размером 2^30 элементов и больше. Проблема возникает при вычислении середины:

mid = (low + high) / 2;

На очень больших массивах low + high может вызвать переполнение. Правильнее писать так:

mid = low + (high - low) / 2;

В C такое переполнение может привести к выходу за границы массива и непредсказуемому поведению. В Java это обычно заканчивается ArrayIndexOutOfBoundsException. Та же ошибка затрагивала mergesort и огромное количество других алгоритмов «разделяй и властвуй».

🖥 Java постепенно закручивает гайки вокруг мутации final-полей через reflection. В JDK 26 появятся предупреждения, если код меняет final-поля через Reflection API. Это часть движения к тому, чтобы final снова означал реальную неизменяемость, а не «почти immutable, пока кто-то не сделал setAccessible(true)». Проблема старая: фреймворки, сериализация, DI и cloning часто создавали «пустой» объект, а потом дописывали поля напрямую. Для final это ломает саму идею конструктора, инвариантов и безопасной инициализации. Что предлагает Java-команда вместо этого: - использовать constructor injection вместо field injection - восстанавливать объекты через конструкторы или static factory - для сериализации чаще выбирать records - применять serialization proxy / readResolve - не полагаться на порядок полей в reflection - не превращать private-поля в скрытый публичный протокол - менять final через reflection только как крайний случай Самый практичный вывод для Java-разработчиков: если ваша библиотека, фреймворк или приложение «оживляет» объекты через reflection, пора проверить этот код заранее. Сегодня это может быть просто warning, завтра - реальное ограничение. https://inside.java/2026/04/27/avoiding-final-field-mutation/ #java

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

Java-совет, который кажется мелочью, пока кто-то не сломает вам состояние объекта.

Не возвращайте наружу изменяемые внутренние коллекции.

Плохой вариант:

```java
public List<String> getMembers() {
    return members;
}

Так вызывающий код получает прямой доступ к вашему внутреннему списку. После этого он может сделать:

team.getMembers().clear();

И внезапно вся команда исчезла. Не через метод доменной модели, не через проверку прав, не через бизнес-логику, а просто потому что геттер отдал наружу ссылку на mutable state. Нормальный вариант:

public List<String> getMembers() {
    return Collections.unmodifiableList(members);
}

Или, если нужен безопасный снимок:

public List<String> getMembers() {
    return List.copyOf(members);
}

Разница важная: * unmodifiableList даёт read-only view поверх текущей коллекции * List.copyOf создаёт неизменяемую копию на момент вызова Это защищает инварианты объекта и оставляет вам свободу менять внутреннюю реализацию. Сегодня внутри может быть ArrayList, завтра Set, послезавтра вообще другая структура. Внешний код не должен зависеть от того, как именно вы храните данные внутри. Геттер коллекции - не просто «получить список». Это граница инкапсуляции. Если отдали mutable-ссылку наружу, объект уже не полностью контролирует своё состояние. #java #javadev

💡 Java: вложенные if-else быстро превращают код в лабиринт Когда вся логика уходит в глубокую вложенность, читать метод становится больно: основной сценарий спрятан где-то внизу, а перед ним несколько уровней проверок. Проще использовать guard clauses - ранние проверки с выходом из метода. Было: - проверяем user - внутри проверяем active - внутри проверяем order - внутри проверяем paid - только потом выполняем основное действие Стало: - если user == null - сразу ошибка - если user неактивен - сразу ошибка - если order == null - сразу ошибка - если order не оплачен - сразу ошибка - основная логика остаётся плоской и читаемой Такой код легче: - читать - тестировать - ревьюить - расширять без превращения метода в пирамиду из if Guard clauses - маленький приём, который сильно улучшает чистоту кода.

📌 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

Митап для Java-разработчиков — 18 июня, Екатеринбург В программе 2 доклада от бэкендеров Яндекс Вертикалей про неочевидные продакшн-баги в Java и Spring, переход на Temporal: 🟥 NullPointerException на инициализированном final-поле. Как такое вообще возможно? Расскажет Михаил Черноскутов из Яндекс Путешествий 🟥Переезд со scheduler-сервисов на Temporal. Зачем он понадобился и какие были подводные камни, ответит Герман Михайлов из Яндекс Недвижимости После выступлений участников ждёт «Громкий вопрос» — интеллектуальная игра по мотивам одноимённого шоу. А также нетворкинг с коллегами и единомышленниками. 🗓18 июня (четверг), 18:00 — 22:00 📍 Ельцин Центр, Екатеринбург → Подробности и регистрация

🖥 Java наконец начал подстраховывать разработчика там, где раньше легко прятались баги. В switch expression начиная с Java 14+ компилятор проверяет, что обработаны все возможные значения. Если у вас enum и вы забыли один из вариантов, код просто не соберётся. Это даёт сразу несколько плюсов: - меньше скрытых багов после рефакторинга - безопаснее расширять enum - компилятор сам ловит забытые кейсы Например, добавили в Status новое значение FAILED, но не обновили switch - получите ошибку компиляции, а не сюрприз в рантайме. По сути это маленькая фича, которая экономит много нервов: чем больше проверяет компилятор, тем меньше потом искать ошибки руками.

Docker и Kubernetes: основы разработки под облачную инфраструктуру Курс для тех, кто хочет держать свой стэк и знания актуальными и глубоко разбираться, как устроены Docker, Kubernetes, и современная облачная инфраструктура в целом. 🌐 Чему вы научитесь: 🤩 Создавать облачную инфраструктуру «с нуля» управление и конфигурация серверов с Terraform, Ansible, cloud‑init 🤩 Уверенно работать с Docker: Dockerfile, слои, кэш, многоступенчатые сборки, реестры, безопасность, air‑gapped 🤩 Проектировать многоконтейнерные приложения: паттерны Sidecar, Ambassador, Adapter, проверки (liveness/readiness), DaemonSet и поды 🤩 Настраивать сеть и балансировку в Kubernetes ClusterIP, Services, Ingress, MetalLB, TLS/SNI, сервис‑меши (Istio) 🤩 Организовывать хранение данных: PersistentVolumes / PVC, StorageClasses, резервное копирование. Упаковка в Helm и поддержка через Operator 🥸 Кто мы: R&D-центр Devhands. Автор курса — Николай Ихалайнен, эксперт по СУБД и бекенду (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО. 🗓 Старт курса: 10 июня, 6 недель обучения. Изучить программу и записаться можно здесь. Ждем вас! Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqxNnFKA

Spring Boot: когда нужно контролировать HTTP-ответ полностью Если обычного return user уже мало, в Spring Boot есть ResponseEntity<T>. Он позволяет явно управлять всем ответом: • статусом HTTP • заголовками • телом ответа • обработкой ошибок • поведением API в нестандартных сценариях Пример: пользователь найден - возвращаем 200 OK, тело ответа и кастомный header. Пользователь не найден - возвращаем 404 NOT FOUND без лишней магии. Это особенно полезно, когда API должен быть предсказуемым: фронтенд, мобильное приложение или внешний клиент получают не просто JSON, а нормальный контракт ответа. ResponseEntity<T> - маленькая деталь, которая делает Spring Boot API заметно аккуратнее.

Java-ошибка, которую лучше ловить на компиляции, а не в проде В Java @Override - это не украшение над методом, а простая защита от глупых ошибок. Представь базовый класс:

class Report {
    void print() {
        // ...
    }
}

Ты хочешь переопределить метод, но случайно пишешь prnt() вместо print():

class PDFReport extends Report {
    void prnt() {
        // ...
    }
}

Код скомпилируется. Но метод print() не переопределён. Ты просто создал новый метод с опечаткой, а старое поведение осталось на месте. А теперь добавляем @Override:

class PDFReport extends Report {
    @Override
    void prnt() {
        // ...
    }
}

И компилятор сразу скажет: такого метода в родительском классе нет, переопределять нечего. Вот почему @Override стоит писать всегда, когда переопределяешь метод. Это маленькая аннотация, которая превращает скрытый баг в обычную ошибку компиляции.

🚀 Request ID в Spring Boot - мелочь, которая спасает часы дебага Когда API начинает сыпаться ошибками, главный вопрос не «что сломалось», а «где именно сломалось». Request ID решает эту боль просто: каждому входящему запросу выдаётся уникальный идентификатор, который потом проходит через логи, заголовки и внутренние вызовы. В итоге можно быстро найти весь путь конкретного запроса: • где он пришёл • какой сервис его обработал • на каком шаге появилась ошибка • какие логи относятся именно к нему • что вернуть клиенту или поддержке для расследования В Spring Boot это часто делают через OncePerRequestFilter: генерируем UUID, кладём его в request attribute и добавляем в ответ заголовок X-Request-ID. Это не делает систему быстрее. Зато делает её наблюдаемой. А в продакшене наблюдаемость часто важнее красивой архитектуры на схеме.

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-ах Контроллер должен описывать сценарий запроса, а не превращаться в свалку обработки ошибок.

Spring Boot магия, которая на самом деле просто проверка classpath. @ConditionalOnClass - одна из тех аннотаций, из-за которых Spring Boot кажется умным. Она говорит фреймворку: «Включи этот bean или конфигурацию только если нужный класс реально есть в проекте». Простой пример:

@Configuration
@ConditionalOnClass(DataSource.class)
public class DataSourceAutoConfiguration 
{
    // загружается только если доступен javax.sql.DataSource
}

То есть Spring Boot не пытается настраивать всё подряд. Он смотрит: • есть ли нужная библиотека в зависимостях • доступен ли конкретный класс • можно ли безопасно включить автоконфигурацию Именно поэтому ты добавляешь starter - и внезапно появляется конфигурация для базы, Redis, Kafka, Web MVC или Security. Не потому что Spring «угадал». А потому что нужные классы появились в classpath, и условия автоконфигурации стали true. В этом и есть главный принцип Spring Boot: меньше ручной настройки, больше условий, которые включаются только когда проект к ним готов.

Код на скорости: митап про производительность, ИИ-агенты и бизнес-процессы в Омске! ⚡️ Встречаемся уже 28 мая, чтобы разобраться: ✔️ Как выкрутить на максимум производительность продукта без больших затрат. Спойлер: помогут виртуальные потоки и корутины (можно сделать скрытым текстом). ✔️ Как создать ИИ-агента, который анализирует сбои и борется с мошенничеством. ✔️ Как моделировать процессы в BPMN так, чтобы минимизировать ошибки. В финале митапа — крутой «мафиозно-квизный» нетворкинг. Дата: 28 мая в 18:00 Место: Школа 21 (ул. Ленина, д. 26Б) Регистрация: здесь!

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. Если у вас есть 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, а не случайной правкой перед деплоем.

✔️ Spring Boot может тормозить сам себя из-за одного неаккуратного @ComponentScan В Spring Boot не стоит бездумно писать что-то вроде: @ComponentScan("com.mycompany") На первый взгляд удобно: фреймворк сам просканирует весь пакет и найдет нужные компоненты. Но проблема в том, что он может просканировать слишком много. Это увеличивает время classpath scanning, замедляет старт приложения и иногда подтягивает классы, которые вообще не должны были становиться Spring-компонентами. Лучший вариант - полагаться на дефолтное поведение:

@SpringBootApplication
public class MyApplication { }

По умолчанию Spring Boot сканирует только подпакеты того пакета, где лежит MyApplication. Если нужно явно ограничить область сканирования, указывай конкретные подпакеты:

@ComponentScan({
    "com.mycompany.myapp.product",
    "com.mycompany.myapp.order"
})

Главная мысль простая: @ComponentScan должен быть точным. Чем шире границы сканирования, тем больше лишней работы делает приложение на старте. #SpringBoot #JavaDev #Java #Backend