Java *

Практика Project Loom: как включить preview Structured Concurrency в javac, Maven и Gradle, как использовать ScopedValue для request context и StructuredTaskScope для параллельных вызовов, joiner’ы, timeout и связка обеих фич в одном примере. Примеры под JDK 25+

Безопасность данных сегодня стала главным приоритетом для любого веб-ресурса. Базовым стандартом защиты учетных записей является хеширование паролей. Этот процесс превращает конфиденциальные символы в необратимый код. Без него утечка базы данных мгновенно скомпрометирует пользователей.

Однако обычного хеширования недостаточно из-за угрозы быстрых хакерских атак. Для защиты разработчики применяют «соль» (salt) — случайные данные, добавляемые к паролю. Минус соли в том, что она хранится рядом с хешем и не спасает от мощного перебора. Тогда на помощь приходит «перец» (pepper), скрытый в коде сервера. Его главная проблема — высокий риск потерять доступ ко всем аккаунтам при компрометации самого секретного ключа.

В новом переводе от команды Spring АйО попробуем разобраться в эволюции методов криптографической защиты. Вы узнаете, как правильно комбинировать эти инструменты для надежной аутентификации.

Интернет любит вечные войны: Linux против Windows, Vim против IDE, tabs против spaces. И, конечно, Python против Java. Одни говорят: «Python уже готов для enterprise». Другие считают RPS и стоимость инфраструктуры.

Под катом — история реального выбора для аэропортовой системы AWOS: почему строгая типизация, бинарная переносимость и современный GC перевесили лаконичность — и что стоит попробовать Python-разработчику.

Project Loom меняет привычную модель конкурентности в Java: virtual threads делают потоки дешевле, Scoped Values дают аккуратную передачу контекста, а Structured Concurrency помогает управлять жизненным циклом связанных задач. Разбираем актуальное состояние Loom в JDK 25-27 и что из этого уже можно использовать.

Наверное, каждый, кто занимался эксплуатацией и развитием корпоративных систем, знает эту бесконечную претензию от бизнеса: «Мы столько тратим на IT – а результата ноль. Новых продуктов нет. Или они появляются мучительно медленно». И бизнес по-своему прав. Если из каждого рубля, потраченного на IT, менее 20 копеек уходит на то, что видит клиент – скорость появления новых продуктов будет именно такой, какая она есть - неудовлетворительной.

В этой статье мы разберём реальную задачу на проектирование Maven Multi‑Module: от циклических зависимостей и неправильного использования spring‑boot‑maven‑plugin до смешения ролей агрегатора и родителя. Затем соберём эталонную структуру по лучшим практикам Spring Cloud и Netflix, добавим CI/CD‑диаграмму и научимся запускать сервис локально без Eureka и RabbitMQ.

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Ранее я уже писал обзорную статью про конкретную реализацию клиента для Ollama. Но чем глубже я погружался в код, тем отчетливее понимал: разговор о конкретном клиенте — это разговор о следствии. А мне хочется поговорить о причине. Об инструменте, который делает возможным любой клиент. О Spring AI.

Статья — перевод англоязычного руководства

При написании автотестов мы часто используем параметризацию — запуск одного и того же теста с разными данными. В этой статье мы разберём, какие задачи решает параметризация, как она реализована в JUnit, и как с ней работать в Allure Report.

28 мая. Москва. Java Рок Стар Митап. Ничего лишнего.

В программе: превратности @Transactional в Spring, зачем нужно такое количество языков программирования и, конечно же, офлайн‑общение.

Регистрируйтесь на митап по ссылке.

P. S. А пока присоединяйтесь к нашему ТГ‑каналу и чату Java Rock Stars Meetup, чтобы быть в курсе новостей митапа.

В Netflix тысячи Java-репозиториев. Когда в библиотеку вносят изменение, часть пользователей может перестать собираться или начать работать некорректно. Чаще всгео эта проблема возникает потому, что public контракты являются public только для авторов библиотеки, а не для пользователей.

С новом переводе от команды Spring АйО разбираемся, как ребята из Netflix ввели простые метки для API: @Public - можно использовать снаружи, @Experimental - тоже можно, но интерфейс может меняться, @Deprecated - готовится к удалению. Все остальное считается внутренним и использованию извне не подлежит. Но сами аннотации проблему не решают, нужна проверка на масштабе.

Решение - ArchUnit + Nebula ArchRules. 

ArchUnit анализирует скомпилированный байткод, поэтому одинаково работает для Java/Kotlin/Scala и проверяет реальный код на classpath. Команды пишут правила (например: «вне пакета библиотеки нельзя зависеть от ее deprecated/internal API»), публикуют их как отдельный arch-rules JAR, а runner автоматически запускает проверки в репозиториях и делает отчеты с точной строкой нарушения.

Все сейчас пишут красивый, современный код: стримы, record DTO, функциональные цепочки. Применяют лучшие практики и никаких мутабельных аккумуляторов и ручных циклов.

А потом код начинает виснуть.

И ведь локально все хорошо, и памяти достаточно, но под нагрузкой GC внезапно начинает просыпаться каждые 200 миллисекунд, хотя куча заполнена всего на 40%.

В это статье я приглашаю заглянуть под капот чистого кода и немного развеять иллюзию того что JVM все решит за Вас.

Я не буду указывать правильный путь, а просто возьму два реальных стиля написания одного и того же кода, запущу их в трёх конфигурациях JVM и покажу, в какой момент чистый код внезапно оказывается дорогим удовольствием.

AI-агенты уже стали частью повседневной разработки. Сначала это выглядит как магия: формулируешь задачу, получаешь код, тесты, иногда даже готовый PR.

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

В этой статье разберем, что с этим можно сделать на практике и почему для хорошего результата критически важен правильно подобранный набор инструментов.

Это конспект вебинара. Спикер — Даниил Степанов, разработчик‑исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

AI уже пишет заметную часть промышленного кода, а процессы качества у многих команд остались такими, будто код всё ещё пишет только человек и в прежнем объёме.

Если коротко: проблема чаще всего не в том, что «модель тупая». Проблема в том, что вокруг агента нет инженерного контура: спецификации, ограничений, независимых тестов, security‑checks, ревью‑пайплайна и артефактов, которым можно верить.

Миграции базы данных вроде бы есть, Liquibase подключен, changelog лежит в репозитории, CI зелёный, релизы проходят регулярно. Значит, процесс под контролем?

Не всегда…

Почему добавление второго consumer«а в очередь может привести к двойным списаниям? Разбираем на реальном кейсе: как один Topic стоил компании 312 дублей за час. »

Сравниваем поведение JMS, Kafka и RabbitMQ, показываем, почему ни одна очередь не даёт exactly‑once из коробки, и как идемпотентность, Dead Letter Queue и правильный выбор канала (команды vs события) делают интеграции надёжными.“

Готовые схемы, продакшен‑код на Java и чек‑лист, который стоит применить прямо сейчас!

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

В последней части про модели конкурентности JVM языков мы сравним разные подходы друг с другом. И ответим на вопрос “А зачем теперь тред пулы, если есть столько модных концепций: корутины, файберы, виртуальные потоки ?”

Первая статья из цикла о каналах обмена сообщениями. Разбираем архитектурные дилеммы, конкурирующих потребителей, message storm, гарантированную доставку и лучшие практики команд, работающих с JMS и Kafka.

В Kotlin деструктурирование выглядело так: val (name, age) = person. Но компилятор берет значения не по именам, а по позиции component1/component2.

Отсюда проблемы. Если поменяли порядок параметров в data class или сделали age вычисляемым свойством: то та же строка начинает доставать другое поле. Причем иногда код даже скомпилируется, но, конечно, смысл изменится: val (age, name) = person.

И вот теперь Kotlin эксперементально переводит круглые скобки на деструктурирование по имени. Синтаксис будет такой: (val name, val age) = person. И порядок внутри скобок не важен. Переименование явно: (val years = age, val theName = name) = person.

Позиционное же деструктурирование остается, но переезжает в квадратные скобки для Pair/Triple и коллекций: val [x, y] = point.

Разбираемся полностью в новом переводе от команды Spring АйО.