Java *

Эта статья продолжает цикл воспоминаний разработчика тренажёрных комплексов. Несколько лет назад наша команда столкнулась с задачей создания эмулятора автоматизированной системы управления технологическим процессом (АСУ ТП) для одной из тепловых электростанций. Задача выглядела стандартной и несложной: воспроизвести логику контроллеров, разработать мнемосхемы и запустить модель.

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

Цель настоящей публикации — поделиться опытом разработки эмуляторов АСУ для учебных тренажёрных комплексов, рассмотреть типы симуляций, привести пример архитектуры подобного решения, коснуться используемых технологий и языков программирования, описать часто возникающие трудности и предложить способы их преодоления.

Почти каждый разработчик рано или поздно задается вопросом: «Я уже Middle или все еще уверенный Junior?» Опыт растет, задач становится больше, стек шире — но вместе с этим появляется и иллюзия, что раз ты пишешь на Java каждый день, значит, язык знаешь. На практике же границы между грейдами проходят не по количеству лет в профессии и не по числу реализованных фич. Они проходят по глубине понимания: платформы, архитектуры, производительности, работы с данными и собственных ограничений.

Привет, Хабр! Меня зовут Любовь Кулева, я руководитель отдела разработки и методологии Учебного центра IBS. В 2025 году мы выпустили три полноценные «дорожные карты развития» — для системного аналитика, для архитектора ПО и для бизнес-аналитика. В этой статье поговорим про джавистов: что на самом деле стоит за грейдами и какие компетенции формируют профессионала на каждом этапе.

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

Многопоточность — одна из самых сложных тем в Java. По сути это ситуация, когда несколько потоков работают с общими данными и в процессе работы легко столкнуться с состоянием гонки (race condition), потерей обновлений или даже повреждением структуры данных. Чтобы этого избежать, доступ к критической секции кода нужно ограничить: одновременно там должен находиться только один поток.

В Java есть два основных механизма для решения этой задачи: встроенное ключевое слово synchronized и явные блокировки из пакета java.util.concurrent.locks, наиболее популярная из которых — ReentrantLock. Оба подхода обеспечивают взаимное исключение (mutex), но работают по-разному и подходят для разных сценариев.

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

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

Я работаю с несколькими клиентами, активных проектов в работе около 25 штук, стандартные средства и функционал IntelliJ IDEA(Recent projects) с таким количеством прекрасно справляется, быстро ввел название сервиса в поиск и так же быстро открыл.
Идеальная жизнь закончилась когда ко мне пришел клиент с еще 25 микросервисами в разных репозиториях и беклогом с багами в 300+ задач(white-label решение), я вздохнул и начал работать с 50 активными проектами и обнаружил что "Recent projects" в IDEA умеет хранить только 30 последних открытых проектов, и если ты открываешь 31 проект, увы первый пропадает как из поиска, так и из списка.

Через пару месяцев этот же клиент отправил меня на помощь одному из своих заказчиков, где те же 25 микросервисов, но со своими фичами, функционалом и так далее. По итогу к декабрю у меня образовалось 75 рабочих проектов и с десяток личных, и работать с этим комфортно я не представлялось возможным. Я начал искать какие то готовые решения на просторах магазина JetBrains - нашел три мертвых плагина с плоским функционалом и по факту тем же подходом как в "Recent projects".

Решение — свой плагин со всем функционалом что я хочу, без ограничений IDEA...

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Cтарший инженер-программист в организации JavaScript Infrastructure & Terminal Experience компании Bloomberg Джейсон Уильямс опубликовал пост, в котором рассказал, как он вместе с командой реализовывал библиотеку Temporal вместо Date для различных типов дат и времени. Автор выступает делегатом TC39 (группы экспертов из Ecma International, отвечающей за стандартизацию и развитие языка JavaScript) и имеет опыт стандартизации функций, реализации языка и участия в крупных проектах с открытым исходным кодом. Джейсон также является создателем движка Boa JavaScript.

Работа с агентом обычно прерывается мелкими операциями: написать сообщение коммита, скопировать кусок ответа, прикрепить скриншот. В релизе Veai 5.6 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE) мы убрали часть этой рутины. Добавили генерацию коммитов из diff, быстрые действия для текста ответа, явный технический контекст запроса, ручной вызов Skills и более простой способ прикреплять изображения.

Текст в ленту: AI-агент пишет код. Другой AI-агент его ревьюит. Первый фиксит замечания. Ревьюер проверяет фикс. 9 параллельных субагентов, 18 000 токенов в минуту каждый, и вопрос, который никто не задаёт: а кто проверяет ревьюера?

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

Java-разработчики годами жили по принципу «Everything is an object». И всё бы хорошо, если бы за это нам не приходилось платить «налогом на объект»: каждый раз, когда вы создаёте простой класс из двух полей int, JVM бережно дописывает к нему тяжёлый заголовок, упаковывает в ссылку и разбрасывает по куче, заставляя процессор страдать от постоянных промахов кеша.

Мы привыкли к этому компромиссу. Мы научились использовать примитивные коллекции и костыли, чтобы выжать производительность там, где объектная модель Java начинает буксовать. Project Valhalla призван изменить сами правила игры.

TL;DR: Ваша IDE знает о проекте всё — иерархии типов, ссылки между модулями, исходники библиотек, ошибки компиляции. AI-агент ничего из этого не видит и вынужден грепать код и логи. За один выходной можно написать плагин и CLI, которые выставят семантику IDE наружу — и агент получит те же суперсилы, что и вы. В статье — как это сделано на примере Eclipse и JDT, но подход переносим на любую IDE. Открытый код: github.com/kaluchi/jdtbridge.

Если ваши руки давно привыкли к Ctrl+Shift+G, Ctrl+T, Ctrl+Shift+T и сопротивляются переходу в другой редактор — вы, вероятно, в Eclipse. И вы точно знаете, что ваша IDE понимает код на уровне, который не снился ни одному AI-редактору. Но AI-агент об этом не в курсе, и как следствие, вынужден жечь десятки тысяч токенов на свои grep-ы.

Написал небольшую библиотеку для Spring Boot, которая добавляет типизированные @Conditional-аннотации для работы с конфигурацией через Environment...

Приложение тормозит. Где узкое место? Почему растёт память? Есть ли дедлок?

Я написал JavaPerf — MCP-сервер, который даёт ИИ-инструментам прямой доступ к нативным утилитам JDK для профилирования. Без графических интерфейсов, без ручного CLI — только диалог с ассистентом.

Почему использование JSON как формата сообщений может стать узким местом в высоконагруженных системах? Что такое Apache Avro и Schema Registry?

Простым языком об этих технологиях, их работе и причинах их возникновения.

Статья к открытому уроку курса QA Automation Engineer про начало разработки тестов на языке Java которая погружает в основы синтаксиса.

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

В 2026-м сильный ассистент уже умеет читать репозиторий, запускать команды, собирать изменения в дифф и предлагать готовые PR-ы. 

В этой статье по материалам нашего вебинара разберем, как устроены современные AI-ассистенты, чем они отличаются и на что обращать внимание при выборе решения для enterprise-контура. Ключевые моменты – безопасность кода и данных, on-premise развёртывание, риск уязвимостей в сгенерированном коде и контроль действий AI-ассистентов.

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся со всем сообществом.

В этом выпуске рассказываем, зачем в Java хотят перезапустить проект Detroit. Почему Kubernetes — база для Spring-разработчика. Какое возможное будущее у проверяемых исключений. Как уронить базу, пытаясь обновить кэш. Что такое carrier-классы, которые планируют ввести в Java в будущем. И еще много интересного. Приятного чтения! For those who code after… 🙂

Для российских компаний выбор между серверами приложений на базе Apache Tomcat и WildFly давно перестал быть спором о «любимом стеке разработчиков». Это стратегическое решение, влияющее на устойчивость бизнес‑сервисов, стоимость владения ИТ‑ландшафтом и способность пройти путь импортозамещения без рисков для критичных систем.

В современных условиях ИТ‑инфраструктура почти всегда неоднородна: рядом живут легкие веб‑сервисы и тяжелые транзакционные ядра, экспериментальные микросервисы и строго регламентированные системы, попадающие под КИИ. В такой среде попытка «посадить все на один тип сервера приложений» приводит либо к избыточной сложности, либо к ограничениям по функционалу и масштабируемости.

Гораздо продуктивнее смотреть на сервер приложений на базе Apache Tomcat и сервер приложений на базе WildFly как на два разных типа решений под разные задачи – и выстраивать платформу, которая позволяет использовать оба подхода в едином управляемом контуре.

Вот и закончился февраль, за который в GigaIDE появилось ещё больше полезного. Ниже — краткий обзор обновлений PRO-функциональности GigaIDE, которую можно найти в нашем маркетплейсе. Обзор инкремента за январь доступен по ссылке.