Объектно-ориентированный язык программирования
Вышла 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 не придумала. Она лишь заняла конкретную позицию по ряду вопросов, из чего следуют определённые ограничения и преимущества. Их мы и обсудим.
Команда Spring АйО подготовила перевод статьи о том, как JSpecify наконец превращается из «ещё одного стандарта для библиотек» в рабочую основу null-безопасности для всей Java-экосистемы. IntelliJ IDEA 2025.3 впервые согласовала свои проверки с NullAway, а Spring и JetBrains синхронизировали suppressions и поведение анализаторов. Итог — единый, предсказуемый null-анализ без сотен ложных предупреждений.
Иногда в процессе разработки внезапно выясняется, что привычные подходы к тестированию перестают работать: автотесты громоздкие, данные — одноразовые и неудобные, а тестовые фреймворки уже не спасают. В такой момент команда или буксует, или придумывает что-то новое.
Привет, Хабр! Меня зовут Владимир, я SDET-специалист в компании SimbirSoft. В этой статье хочу рассказать, как мы решали проблемы тестирования не традиционным написанием автотестов, а созданием собственных REST-сервисов: сервиса генерации данных и сервиса, ассистирующего тестам.
Привет, Хабр!
В этой статье рассмотрим, как масштабировать UI-автотесты с помощью Java.
Если у вас десяток тестов, проблем не возникнет, они бегают шустро и всем довольны. Но представьте абстрактный проект интернет-банка или маркетплейса, функциональность растёт, количество автотестов идёт на сотни (а то и тысячи). Последовательный запуск такой тестовой свиты может занять довольно большое время. Каждый релиз начинает тормозиться ожиданием результатов автотестов.
Масштабирование тестов решает эту проблему: запускаем тесты параллельно, сокращаем время прогона и получаем быстрый фидбэк о качестве.
TL;DR
Мы собрали рабочего ИИ‑агента‑разработчика, который сам анализирует задачи в Jira, уточняет детали, пишет код, запускает сборку, фиксит ошибки, создаёт MR в GitLab и отправляет его человеку на ревью. Он работает параллельно на нескольких задачах, благодаря чему суммарное время выполнения пачки задач падает почти втрое. Команда избавилась от рутины, а скорость разработки выросла без расширения штата.
Использовали: Ollama + Qwen3 Coder, PostgreSQL, Docker, GitLab/Jira API, систему строгих JSON‑действий.
Столкнулись с контекстом, «галлюцинациями», GPU и самовольными правками кода — всё решаемо архитектурой.
ИИ не заменяет разработчиков, он снимает тупую монотонную работу и экономит деньги.
Практическое руководство по интеграции JNI + полный пример
Сегодня и Rust, и Java широко используются, но каждый из них по-своему хорош в своей области. В реалистичных сценариях часто бывает полезно комбинировать Rust и Java, чтобы одновременно повысить эффективность и системного кода, и кода приложений.
Configuration cache должен был стать обязательным в Gradle 9, но требования, в итоге, смягчили. В любом случае, рано или поздно он станет обязательным и авторам плагинов придется его поддерживать.
Я не могу сказать что документация по кэшу плохая, но в ней очень мало практики: каждому разработчику приходится тратить время на эксперементы. Так вот, под катом те самые недостающие эксперименты - как работает gradle configuration cache на примерах.