Fluent API. Часть 2 — а оно нам надо?

Продолжаем разговор о Fluent API. И теперь, после того как мы из предыдущей статьи (или/и личного опыта) узнали о том что это чудо из себя представляет давайте разберемся зачем оно нужно?

Объектно-ориентированный язык программирования

Продолжаем разговор о Fluent API. И теперь, после того как мы из предыдущей статьи (или/и личного опыта) узнали о том что это чудо из себя представляет давайте разберемся зачем оно нужно?

В то время как аналитики жарко спорят на тему станет ли основным языком программирования 6-го (видимо) поколения английский или все-таки китайский предлагаю поговорить немного на другую тему, но в том же направлении: как сделать код программы ближе к человеку?
Один из ответов на этот вопрос зародился еще в 70-х годах прошлого столетия как method chaining в рамках языка Smalltalk и, благодаря стараниям Эрика Эванса и Мартина Фаулера дошел до нас как Fluent API.

После создания примерно десятка Telegram-ботов я понял, что архитектура, конфигурации и маршрутизация повторяются из проекта в проект. Готовых актуальных решений для Spring Boot я не нашёл. Поэтому разработал собственный Telegram Bot Spring Boot Starter: с прозрачным пайплайном, набором готовых компонентов и возможностью гибкой кастомизации.
В статье я расскажу, какие проблемы он решает, как устроен внутри, как его использовать и почему он оказался намного удобнее обычных self-made конфигураций.

В мире разработки часто возникает соблазн использовать знакомый инструмент для всех задач. Зачем изучать что-то новое, если есть проверенная реляционная база данных (РСУБД), такая как PostgreSQL или MySQL? Однако, когда дело доходит до реализации мощного, быстрого и релевантного поиска, этот подход терпит неудачу.
Elasticsearch — это не просто база данных, это распределенный поисковый и аналитический движок. В этой статье мы проведем детальное сравнение Elasticsearch и реляционных баз данных, разберемся в их архитектурных различиях и определим, когда каждый из инструментов становится титаном в своей нише.
Чтобы статья была максимально практико-ориентированной, мы рассмотрим, как с помощью Spring Boot быстро поднять приложение с интегрированным Elasticsearch и реализовать поиск, который «летает».

Что, если ваш валидатор стал бы в 3 раза быстрее и потреблял бы вдвое меньше памяти — без единой правки бизнес-логики? Именно это случилось с Hibernate Validator 9.1: ушли тяжёлые коллекции, пришёл умный стек. Каскадная валидация теперь летает, даже при циклах в графе объектов.
Плюс бонус: меньше мусора в памяти, меньше аллокаций, быстрее интерполяция сообщений. В бенчмарках — просто космос. Все это – в новом переводе от команды Spring АйО.
Комментарий Поливаха Михаила: Несмотря на то, что с валидацией мы напрямую работаем не часто, имейте в виду, что Spring Boot и ваши @RestController-ы под капотом всё равно используют hibernate-validator. Поэтому почитайте, не поленитесь.

Всем привет! Иногда внутренний мониторинг не даёт полной картины, что все работает как надо. И полезно сделать внешний пинг и посмотреть, действительно ли нужный проект доступен.
Сегодня мы расскажем, как решали эту задачу для себя, и выложим код в Open Source, который вы сможете применить для простого мониторинга своих проектов. И да, мы знаем про существование специализированных сервисов для решения этой задачи, но всегда веселее написать свой скрипт.

Продолжаю серию публикаций про наши Java-онлайн курсы. Предыдущие посты:
Тесты на дженериках. Параметризация AssertJ и сравнение Json через объекты
Контроллеры на дженериках: пишем кода в 3 раза меньше
Миграция Java Spring Boot на Kotlin
Как многие знают, недавно вышел Spring Boot 4 / Spring 7.0. В постах компании@spring_aio есть несколько статей по новому функционалу.
Я мигрировал наш небольшой учебный демо-проект Spring Boot 3.x HATEOAS (ссылка на GitHub) на Spring Boot 4 и добавил API версионирование. В статье даю ссылки на новый функционал, описываю шаги миграции и код проекта. Буду рад читателям:)

Вышла OpenIDE 2025.2 — первая российская IDE с поддержкой Java 25. Мы идём в ногу с платформой и остаёмся на самом острие технологий. Но не только этим релиз интересен: в нём появилась улучшенная отладка виртуальных потоков, обновления связанные с UI, а ещё пара важных обновлений экосистемы.
Поехали по порядку.

Команда Spring АйО подготовила перевод разбора реального бага в HotSpot от разработчика OpenJDK. Во время работы над Project Valhalla его Java-объекты и классы начали «исчезать» без участия сборщика мусора — и поиск причины привёл к одному неверному биту в заголовке объекта, miscompilation в C2 и очень нетривиальному отладочному квесту. Этот текст показывает, как устроены mark word и Compact Object Headers, чем живёт Valhalla и как системное мышление плюс флаги JVM помогают выловить самые коварные ошибки.

Три способа менять один объект из нескольких потоков. Больше нет
Mutex, CAS, акторы, STM, CRDT, иммутабельность, MVCC, Disruptor…
Когда читаешь про многопоточность, кажется, что способов — десятки, и каждый требует отдельного изучения.
На самом деле их ровно три. Всё остальное — реализации и комбинации.
Эта статья — попытка навести порядок в голове. После неё вы сможете:
за 5 секунд классифицировать любой подход к конкурентности;
понимать, почему Erlang выбрал акторы, а Java предлагает synchronized;
не изобретать велосипеды и не зацикливаться на «единственно правильном» решении;
проектировать многопоточный код, держа в голове простую модель.
Заодно, покажу почему ООП вообще не было изначально спроектировано под многопоток.

На конференции Joker 2025 у нас была отличная возможность понять, как живётся Java-сообществу.
Как AI влияет на Java-разработку? Вайб-кодинг — полезный инструмент или угроза рабочим местам? Spring — незаменимый фреймворк или слишком тяжёл для многих задач? Что с рынком труда и зачем кандидаты накручивают опыт? И главное — зачем писать на Java, если есть JavaScript?

От переводчика: статья немного сокращена по сравнению с оригиналом, исключён раздел об этимологии слова "Ouroboros", а также полные каламбуров отсылки автора к латинским, прочим романским и английским корням.
Далее - от автора.
Можно ли создать язык программирования, в котором нет синтаксиса? Кажется, что это чистое противоречие. Вся суть языков программирования заключается в синтаксисе, плюс немного в генерации и оптимизации кода, настройке сред выполнения и т.д. Но с точки зрения программиста — именно синтаксис самая важная часть языка. Когда вы приступаете к изучению нового языка программирования, вам обязательно придётся уделить время освоению синтаксиса.
Можно ли просто избавиться от синтаксиса или, как минимум, предельно его упростить? Другой вариант — можно ли сделать синтаксис произвольным, чтобы программист, пишущий код, мог сам для себя его определять?
Именно этих целей мы попытались достичь, создав язык Ouroboros. Его синтаксис максимально прост. Настолько, что в этом языке даже не предусмотрен синтаксический анализатор. В нём есть только лексический анализатор, код которого составляет 20 строк.
Привет, Хабр! Хочу поделиться опытом разработки такой системы. Определяющими параметрами проблемно‑ориентированной системы являются.

Статья демонстрирует построение минималистичного MapReduce-фреймворка на Scala для локальных экспериментов. Рассматриваются стадии Map, Shuffle и Reduce с ленивыми вычислениями через Iterator, а также абстракции ввода/вывода IO и локальные исполнители с виртуальными потоками.

Приветствие
Всем привет!
Прошло целых 3 месяца с момента публикации первой статьи. Очень мало свободного времени было для дописывания всех тех фичей, которые я изначально запланировал в плагин. И вот, наконец-то, появилась возможность закончить, когда-то начатый путь, и привести этот плагин к какому-то логическому завершению. В этой статье я хочу поделится своими наработками, мыслями и дальнейшими планами, да и просто оставить это как заметку о работе над пет-проектом.

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся со всем сообществом.
Этот месяц в мире Java выдался насыщенным. В JDK 26 готовят превью Lazy Constants и Structured Concurrency, собираются убрать режим строк только UTF‑16, а стандартный HttpClient получает более гибкую поддержку TLS.
Главное событие — GA‑релизы Spring Framework 7 и Spring Boot 4: модульная автоконфигурация, новый HTTP‑клиент, версионирование REST API, переход на Jackson 3 и множество других улучшений.
Из практики: разбор пагинации в Spring Data JPA, подводные камни MapStruct и заметка о балансе между чтением и написанием кода. Приятного чтения!

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.
Возможно, причиной восторга стала мысль о том, что я смогу снова разнести его примеры кода, как сделал в своей первой статье.
Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.
А может, это была глубинная надежда, что кто-то, наконец, пересмотрел его идеи и осознал необходимость изменения подхода Мартина к написанию «чистого кода». Всё же это была самая жестокая критика первой редакции книги с момента её публикации более 17 лет назад.
Несмотря на весь свой цинизм и любовь постебаться, я искренне уважаю тех, кто может признать свои ошибки и взглянуть на вещи по-новому. Я испытываю глубокую радость, когда мой посыл доходит до умов людей и меняет их взгляд на вопросы, в которых они грубо заблуждаются (хотя порой мне кажется, что мой напористый подход может, наоборот, этому мешать).
Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!
Невероятно!
Но я забегаю вперёд…

Реляционные базы данных по-прежнему остаются главным хранилищем наших данных. А значит, вопрос выбора инструмента отображения данных из БД на уровне приложения - всё так же актуален.
Долгое время я выбирал: Spring Data JPA. Уверен, что большинства из вас — тоже. Но времена меняются, и в 2025 для своих новых проектов я использую — Spring Data JDBC.
Почему? Если вам стало любопытно — добро пожаловать под кат.

Привет, Хабр! Меня зовут Максим Шишкин, я инженер по нагрузочному тестированию в команде Platform V Works::Artifactory в СберТехе. Наше решение — менеджер репозиториев артефактов и контейнеров. Он позволяет организовать хранение, описание, тегирование сборок и дистрибутивов программных продуктов, а также готовых Docker-контейнеров.
В этой статье я расскажу, как и почему мы перешли на Java 17, как протестировали возможности нового сборщика мусора Z Garbage Collector и в результате сэкономили ресурсы виртуальных машин — а вместе с этим и финансы. Надеюсь, наш опыт будет полезен инженерам по сопровождению, командам разработки и тестирования.

Данная публикация является переводом статьи Jeff-a Atwood-а почти 20-ти летней давности. Jeff Atwood, один из фаундеров StackOverFlow, написал эту статью как некоторое резюме того, как человечество боролось с проблемой O/R Impedance Mismatch.
Я частично принимаю участие в написании разных ORM решений, например, Spring Data JDBC / R2DBC, и скоро мы вместе с Amplicode проведем online событие (оно бесплатное) по Spring Data JDBC. Будем обсуждать Spring Data JDBC, что в ней хорошо а что в ней плохо. Какие trade-off-ы она имеет.
Я решил выпустить данный перевод с целью того, чтобы напомнить людям - silver bullet-а Spring Data JDBC не придумала. Она лишь заняла конкретную позицию по ряду вопросов, из чего следуют определённые ограничения и преимущества. Их мы и обсудим.