Java Portal | Программирование

WebFlux часто вызывает путаницу, потому что его обычно объясняют со стороны инструмента, а не со стороны проблемы. Поэтому начнем с базы. Сначала: блокирующий vs неблокирующий код -» Блокирующий код: Поток встает и ждет, пока операция не завершится. Пока ждет, он ничего больше делать не может. -» Неблокирующий код: Поток делегирует ожидание и остается свободным для других задач. Когда результат готов, выполняется продолжение. Это не быстрее. Это просто более эффективное использование потоков. Еще одно ключевое понятие перед тем как идти дальше: Backpressure. Это способность системы регулировать поток данных, чтобы не перегружать потребителя. Представь так: потребитель может сказать продюсеру: «присылай только столько, сколько я успеваю обработать». Теперь к WebFlux. WebFlux позволяет строить полностью неблокирующие приложения end-to-end: -»Неблокирующий сервер (Netty) -»Неблокирующие API -»Проброс backpressure без перегрузки потребителя -»Реактивная модель (Mono, Flux) Ключевое слово здесь end-to-end. Если хотя бы одна часть блокирует, весь выигрыш размывается. Самая частая ошибка при работе с WebFlux Использовать WebFlux, а потом: -»Дернуть блокирующую базу данных -»Использовать SDK без реактивной поддержки -»Делать .block(), потому что так проще В итоге: -»Все равно все становится блокирующим -»Ты просто добавил сложности -»Ничего не выиграл WebFlux не превращает блокирующий код в неблокирующий. А Virtual Threads разве это не меняют? Меняют, и это важно. С Virtual Threads: -»Блокирующая модель снова становится жизнеспособной -»Цена ожидания резко падает -»Необходимость в WebFlux уменьшается Но есть нюанс. Virtual Threads не дают: -»Backpressure -»Контроль потока -»Композицию стримов -»Настоящий стриминг данных Они меняют tradeoff, но не убирают саму проблему. Когда WebFlux все еще имеет смысл WebFlux оправдан, когда: -»Нужен реальный backpressure -»Ты работаешь с непрерывными стримами (SSE, WebSockets) -»Есть fan-out из множества внешних вызовов -»Нужно явно контролировать поток данных По необходимости, а не потому что модно. Когда не стоит использовать WebFlux -»Классический CRUD -»Сложная бизнес-логика -»Команды без реактивного опыта -»Проекты, где читаемость важнее конкурентности -»Когда Virtual Threads решают задачу с меньшей когнитивной стоимостью WebFlux это другая модель исполнения. Если твоя проблема не в масштабной I/O-конкурентности, WebFlux тебе не поможет. А сегодня, с Virtual Threads, многим он уже просто не нужен. 👉 Java Portal

Нужно загрузить ресурсы в Spring? Вот несколько рекомендуемых подходов: -» @Value + Resource для classpath, файловой системы и URL -» ResourceLoader для путей, которые определяются во время выполнения -» ResourcePatternResolver для загрузки по шаблонам У каждого варианта своя зона применения. Разбираем, когда и что использовать 👉 Java Portal

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

Совет по Java: используйте default-методы в интерфейсах для поддержки обратной совместимости (начиная с Java 8). Допустим, у вас есть интерфейс Shape:

interface Shape {
   double area();
}

Типичная реализация выглядит так:

class Circle implements Shape {
   private double radius;

   Circle(double radius) {
      this.radius = radius;
   }

   @Override
   public double area() {
      return Math.PI * radius * radius;
   }
}

Теперь нужно добавить метод perimeter(). Если добавить обычный метод в интерфейс, все существующие реализации Shape сломаются. Вместо этого можно добавить default-метод.

interface Shape {
   double area();

   // Новый метод
   default double perimeter() {
      ...
   }
}

Класс Circle автоматически получает реализацию default-метода. При необходимости его можно переопределить. пример : https://gist.github.com/mcasari/b0ee1d94046793ba20f02538ef916f48 👉 Java Portal

Postgres 18 получил поддержку виртуальных вычисляемых колонок. Вычисляемые STORED-колонки в Postgres уже были несколько версий подряд. Вычисляемые колонки позволяют: • создавать колонку на основе других данных • ссылаться на значения из других колонок • заранее считать колляции или любые вычисления в базе, а не в приложении Синтаксис GENERATED ALWAYS AS открывает выражение, а в конце указывается режим VIRTUAL или STORED. Виртуальные вычисляемые колонки пересчитываются при каждом чтении, поэтому не подходят для тяжёлых вычислений. Для таких случаев лучше использовать STORED-колонку или даже expression index. Но они удобны, когда значение нужно редко и его логично вычислять на лету. Пример:

CREATE TABLE products (
id serial PRIMARY KEY,
price numeric,
tax_rate numeric DEFAULT 0.05,
total_price numeric GENERATED ALWAYS AS (price * (1 + tax_rate)) VIRTUAL
);

👉 Java Portal

Представь, что тебя связали, кинули в багажник и увезли в ангар за городом Похититель наклоняется к твоему уху и шепчет: "Или ты правильно отвечаешь на 3 вопроса, или пуля летит тебе прямиком в висок: 💚Почему @Transactional в Spring не работает, если вызвать метод внутри того же класса? 💚Почему Kafka с exactly-once семантикой в 3 раза медленнее обычной и когда можно на это забить? 💚2 запроса одновременно читают баланс 1000₽, вычитают по 600₽ и сохраняют - что окажется в бд? " Ну как? Выживешь в такой ситуации? А ведь именно так сейчас выглядит рынок найма - эти вопросы взяты с реальных собесов 😯 Рынок усложнился, и на вакансию джуна спрашивают как на синьора 3 года назад. Нужно реально шарить, и шарить глубоко, только на одних нейронках далеко не уедешь Чтобы разобраться раз и навсегда со Spring, Kafka, Redis Паша Сорокин 18 декабря в 19:00 по МСК проведёт живой открытый урок для Java-разработчиков и тех, кто хочет им стать: 💚 За какие темы надо шарить, чтобы получить оффер на миддла 💚 В каком порядке и до какой глубины их изучать 💚 По каждой технологии (Spring Boot, HTTP, REST, Postgresql, Hibernate, микросервисы, Kafka, Redis) разберут как делать не надо и как делать надо 🟢 Ссылка на урок будет в закрытом канале урока В этом же канале вас ждёт подарок - гайд "Roadmap из 11 шагов до ЗП в 200.000+" P.S. Паша - ex Senior Dev в ВТБ с 6 годами коммерческого опыта, так что фигни не посоветует))

Java tip : можно использовать List.of() и Set.of(), чтобы создавать неизменяемые (immutable) коллекции. Это быстрый способ получить немодифицируемые списки и множества без Collections.unmodifiableList(). Пример:

List<String> letters = List.of("A", "B", "C");

❌

letters.add("D"); // исключение во время выполнения

👉 Java Portal

Больше десяти лет RestTemplate был главным вариантом для HTTP-запросов в Spring. Прямолинейный. Синхронный. Простой.

Он больше не развивается: новых фич и улучшений не будет, плюс есть ограничения по ошибкам и расширяемости.

С выходом Spring Framework 6 и Spring Boot 3 пришла современная замена: - RestClient ❓Чем обычно характеризуется RestTemplate - API на методах (getForObject, postForEntity и т.д.) - Очень явные вызовы под каждую HTTP-операцию - Мало “цепочек”: часто один вызов укладывается в одну строку - Настройки раскиданы по разным местам (interceptors, error handlers, converters) - Синтаксис исторически нарастал кусками годами Типичный пример:

RestTemplate rest = new RestTemplate();
ResponseEntity<User> response =
    rest.exchange(url, HttpMethod.GET, request, User.class);

Работает, но когда запрос усложняется (headers, auth, ошибки, таймауты), читаемость начинает страдать. ❓RestClient меняет подход к API - Флюентный, декларативный синтаксис - Четкое разделение между сборкой request и чтением response - Лучше читается, когда есть headers, params, auth и т.п. - Единый, консистентный API для всех HTTP-методов - Централизованный builder для общей конфигурации Типичный пример:

User user = client.get()
    .uri(url)
    .header("Authorization", token)
    .retrieve()
    .body(User.class);

Это та же идея, что у RestTemplate, но API яснее, расширяемее и проще поддерживать. ❓Зачем RestClient, если уже есть WebClient WebClient реактивный и неблокирующий (под другую задачу) RestClient работает как RestTemplate: обычный (не реактивный) и с ожиданием ответа, просто это его современная замена. Многим нужен современный API, но без перехода на реактивный стек. Spring не пытается всех загнать в WebFlux. Он просто обновил классический HTTP-клиент.

❓RestTemplate “мертв”

Нет, он не умер, просто его только поддерживают: багфиксы и совместимость, без новых фич. То есть новых возможностей не будет. Только апдейты совместимости. А развитие будет происходить в RestClient. Причем RestClient можно создать на базе RestTemplate:

RestTemplate oldRestTemplate;
var restClient = RestClient.create(oldRestTemplate);

❓Что использовать сегодня: Используй RestTemplate, если: - приложение легаси - миграция слишком дорогая - завязан на библиотеки, которые работают только с RestTemplate Используй RestClient, если: - ты на Boot 3 / Spring 6+ - хочешь современный и чистый API - хочешь остаться в императивном стиле - не хочешь или не можешь использовать WebFlux RestTemplate это классика, почти любой Java-разработчик на Spring хотя бы раз с ним сталкивался. Но RestClient задает точку старта для нового. Это не про реактивность и не про переделку архитектуры. Это просто современный HTTP-клиент, который делает код понятнее и проще в сопровождении. Похоже на подход многих других модулей Spring, где builder упрощает создание объектов и использование классов. И в мире, где сервисы постоянно дергают внешние API, хороший HTTP-клиент реально важен. 👉 Java Portal

Java tip: используй Files.walk(), чтобы рекурсивно пройтись по файлам в каталоге.

public static void main(String[] args) {
    Path startPath = Paths.get("src");

    try (Stream<Path> paths = Files.walk(startPath)) {
        paths
            .filter(Files::isRegularFile)
            .filter(path -> path.toString().endsWith(".java"))
            .forEach(System.out::println);
    } catch (IOException e) {
        e.printStackTrace();
    }
}

👉 Java Portal

Твой Dockerfile не "простой". Он просто недописан. Большинство девов за всю жизнь используют всего 5 инструкций Dockerfile: FROM, COPY, RUN, EXPOSE, CMD, ну и иногда ENV, если уж прям заморочились. 😱 Вот почему твоя команда Ops и пользователи молча тебя ненавидят. Вот несколько инструкций, про которые ты, скорее всего, не знаешь: - HEALTHCHECK: контейнер не становится здоровым только потому, что он запущен. Нет, Kubernetes сам не поймет, что приложение внутри уже сдохло. Скажи ему, как это проверять. Или дай Ops’ам удовольствие дебажить цикл перезапусков контейнеров в проде. - SHELL: По умолчанию это /bin/sh -c. Хочешь другое, используй SHELL. Меньше экранирования, меньше проблем с кроссплатформой. - STOPSIGNAL: не оставляй приложение подвисшим. Задает сигнал, который Docker отправляет при остановке контейнера. Используй тот сигнал, который твое приложение реально обрабатывает. Больше никаких зомби-контейнеров и сломанной "корректной остановки". - ONBUILD Хочешь сделать базовые образы умнее, используй это. Хочешь развалить чужой пайплайн, используй неправильно. - ARG vs ENV: перестань путать "во время сборки образа" и “во время запуска контейнера”, ARG: существует только во время сборки ENV: остается в финальном образе Если ты не понимаешь разницу, не удивляйся, когда приложение ведет себя по-разному на dev и в prod. - LABEL: метаданные не опциональны. Это не для красоты. Это нужно инструментам, CI и аудиторам. Потом сам себе спасибо скажешь. Dockerfile это не шелл-скрипт. Это продовый код. Он описывает систему, которую ты поставляешь. Ты же не выкатываешь наполовину сделанное API, так перестань выкатывать наполовину сделанные образы. Научись писать Dockerfile, который не отстой. 💩 👉 Java Portal

Java-совет: когда нужно наполнять значения в Map, например списки, удобно использовать computeIfAbsent(). Классический способ:

Map<String, List<String>> map = new HashMap<>();
if (!map.containsKey("key")) {
    map.put("key", new ArrayList<>());
}
map.get("key").add("listValue");

С использованием computeIfAbsent:

map.computeIfAbsent("key", k -> new ArrayList<>())
   .add("listValue");

👉 Java Portal

Вышел релиз IntelliJ IDEA 2025.3! В этой версии завезли несколько заметных обновлений – все они подробно описаны и показаны в демках на странице “Что нового”. Зацени 👉 Java Portal

Изоляция рунета ближе, чем ты думаешь

Loading … ██████████████] 99%

Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.

Совет по Java: возвращайте Collections.emptyList(), List.of() или Set.of() вместо null, чтобы не плодить проверки на null в вызывающем коде.

// ❌ Нужен null-check:

public List<String> findUsers() {
    if (!dataAvailable()) {
        return null; // заставляет вызывающий код проверять на null
    }
    return loadUsers();
}

List<String> users = findUsers();
if (users != null) {
    users.forEach(System.out::println);
}


// ✅ Без null-check:

public List<String> findUsers() {
    if (!dataAvailable()) {
        return Collections.emptyList(); // или List.of()
    }
    return loadUsers();
}

// Вызывающая сторона:
List<String> users = findUsers();
users.forEach(System.out::println); // проверка на null не нужна

👉 Java Portal

Статья на вечер: где автор сделал свой Spring Boot Starter для разработки Telegram-ботов на Java, чтобы больше не копипастить одни и те же настройки и логику. Он обернул работу с java-telegram-bot-api в удобный фреймворк с маршрутизацией апдейтов, хендлерами, обработкой ошибок и простым подключением к Spring-приложению. 👉 Java Portal

Spring Boot не прощает клевету на Java 👉 Java Portal

Java-совет : вместо HashSet для enum-типов лучше использовать EnumSet. Он работает быстрее и потребляет меньше памяти. 👉 Java Portal

Учись разрабатывать API с нуля! 🤓 Этот ресурс бесплатный и включает: ✓ Пошаговый курс по REST API и GraphQL ✓ Как добавить безопасность в свои API ✓ Как монетизировать API → http://rapidapi.com/learn 👉 Java Portal

Часто мы пишем public static void main и просто предполагаем, что Java сама «делает свою работу». Но за этим стоит довольно сложная и интересная система , а именно ClassLoader’ы. Именно они отвечают за то, чтобы находить, проверять и загружать каждый класс, который использует твоё приложение. Без ClassLoader’ов нет JVM, нет Spring, нет плагинов, вообще ничего нет. Что такое ClassLoader? Это компонент JVM, который отвечает за: - Поиск определения класса (файлы .class, JAR’ы, модули). - Загрузку его в память. - Проверку байткода на валидность и безопасность. - Определение класса в изолированном пространстве. Проще говоря, он превращает байткод в то, что JVM может исполнять. Иерархия держит хаос под контролем В Java используется модель делегирования вверх {parent delegation} Это защищает от конфликтов, дублирования и неожиданных подмен классов. Основные загрузчики: - Bootstrap ClassLoader Написан на C++, загружает базовые классы языка (java.lang.*, java.util.* и так далее). Живёт прямо внутри JVM. - Platform / Extension ClassLoader Загружает библиотеки самого JDK и системные модули. - Application ClassLoader Загружает твои классы, зависимости и весь прикладной код. Типичный поток загрузки выглядит так: Когда ClassLoader пытается загрузить класс, он сначала делегирует запрос родителю. Если родитель не находит класс, тогда уже текущий загрузчик пытается загрузить его сам. Это не даёт тебе случайно переопределить String, List, Object и другие базовые классы. Как загружается твой код? Когда ты запускаешь JAR:

java -jar app.jar

Твой код загружает Application ClassLoader. Процесс простой: - Проходит по classpath - Открывает JAR’ы - Находит .class - Загружает их по мере необходимости Загрузка классов происходит по требованию. Если у тебя 200 классов, а реально используются только 10, будут загружены только эти 10. Почему это реально важно? Потому что всё, что мы используем поверх Java, строит свою работу на ClassLoader’ах: Spring Boot создаёт собственный ClassLoader для загрузки fat JAR’ов. Модульные приложения используют загрузчики для изоляции компонентов. Веб-контейнеры вроде Tomcat создают отдельный ClassLoader на каждое приложение. Плагины (IDEA, Jenkins, Minecraft, OSGi) работают через отдельные загрузчики. Инструменты hot reload (Spring DevTools, JRebel) зависят от динамической перезагрузки классов. Зачем это понимать на практике? Рано или поздно ты столкнёшься с ошибками вида ClassNotFoundException. Понимание ClassLoader’ов даёт отличную точку старта для отладки. Самые частые проблемы: ClassNotFoundException — класс отсутствует в classpath текущего загрузчика. NoClassDefFoundError — класс был доступен, но возникла ошибка при загрузке или верификации. “Невозможный” ClassCastException — объект вроде бы нужного типа, но Java считает иначе. Обычно это означает, что один и тот же класс был загружен разными ClassLoader’ами. Memory leak в веб-приложениях — Tomcat некорректно выгружает ClassLoader при redeploy. Последнее происходит значительно чаще, чем кажется. ClassLoader’ы это как кровеносная система Java ( их не видно, но без них ничего не работает. ) Понимание того, как Java загружает классы это не пустая теория. Это делает тебя сильнее в отладке, увереннее при разборе сложных багов и даёт чёткое понимание среды, в которой реально работает твоё приложение. И когда в продакшене что-то падает с ClassNotFoundException, ты точно будешь рад, что разобрался в этом заранее. 👉 Java Portal

Похоже, это претендент на TUI года ⭐️ gitlogue — инструмент для «кинематографичного» воспроизведения Git-коммитов прямо в терминале. Смотри, как коммиты развертываются с анимацией ввода, подсветкой синтаксиса и живым обновлением дерева файлов. Буквально наблюдай, как твой репозиторий пишет себя сам. Написан на Rust GitHub: https://github.com/unhappychoice/gitlogue 👉 Java Portal