Axiom JDK

🫨 Python и JavaScript теперь будут в Java?  Inside.java опубликовал доклад о Project Detroit. В OpenJDK исследуют, как встраивать в Java-приложения готовые движки V8 и CPython через FFM API. Зачем это надо? Допустим, Java-сервису нужен Python-код для анализа данных или JavaScript-сценарий с бизнес-правилами. Сейчас для этого нередко запускают отдельный процесс, настраивают API и обмен данными. Detroit предлагает выполнять такой код прямо в Java-приложении, в том же процессе, через знакомый javax.script. Почему не написать свой движок?  Это уже пробовали с Nashorn в JDK 8. Но JavaScript быстро менялся: поддерживать совместимость становилось всё дороже, а движок отставал от новых возможностей языка. В JDK 11 Nashorn пометили устаревшим, а в JDK 15 удалили. Теперь ставка на оригинальные runtime, которые развиваются вместе с языками. Если подход сработает, Java сможет использовать инструменты других экосистем без сторонних сервисов. Звучит удобно, но вот как будет реализовано взаимодействие сборщиков мусора, управление памятью и виртуальные потоки — пока вопрос. Как считаете, получится? 🔷 Доклад о Project Detroit на Inside.java

Создаем DMS на Java: RAG для корпоративных документов 🧑‍💻   Как встроить ИИ в работу с документами: от классификации и заполнения реквизитов до RAG-поиска с учетом прав доступа?   11 ноября на техническом воркшопе разберем это на полноценной DMS (Document Management System) - системе управления документами на Джеймикс.   ⭕️ Начнем с приложения и его архитектуры.  Покажем, как устроена DMS и какие действия пока приходится выполнять вручную: заполнять реквизиты, искать ответы в договорах и подбирать ключевые слова для поиска.   ⭕️ Встроим ИИ в работу с документами.  Покажем определение типа документа, заполнение реквизитов и ассистента в карточке: краткое содержание и ответы по тексту.   ⭕️ Перейдем в Java-код.  Разберем реализацию ИИ-инструментов с AI Tools: как передавать модели контекст и вызывать функции приложения.   ⭕️ Разберем RAG в действии.  Покажем векторный индекс и поиск по смыслу. Загрузим новый документ и найдем его через ассистента.   ⭕️ Проверим права доступа.  Посмотрим на систему под разными пользователями и покажем, как ограничить контекст модели только разрешенными документами. Обсудим ошибки и ограничения реализации.   Вы получите исходный код готовой DMS с ИИ-функциями и сможете использовать его как основу для своих проектов. Расскажем, как запустить приложение у себя, и ответим на вопросы.   Для погружения в техническую часть потребуется знание Java.   📆 11 ноября, 16:00 по МСК 🕰 60 минут + 20 минут на вопросы   🔗 Регистрация здесь.   Зарегистрируйтесь, чтобы получить запись воркшопа на почту.

😐 71 CVE в Spring за июнь: что это значит? Уязвимости продолжают находить в огромных количествах. В июне Broadcom раскрыла 71 CVE в экосистеме Spring. 31 из них — уровня High. Для сравнения: за весь 2025 год было выявлено 16 уязвимостей.   К счастью, это не значит, что 71 дыра есть в каждом Spring Boot-приложении. Уязвимости затронули Spring Framework, Security, Data, Kafka, Micrometer и другие проекты. Среди рисков — DoS, обход аутентификации, небезопасная десериализация. Часть библиотек попадает в сборку транзитивно. ❓ Что делать командам? Важно не число CVE само по себе, а то, затронута ли ваша сборка. Нужно знать прямые и транзитивные зависимости, сверять версии, конфигурацию и условия атаки. И следить за исправлениями компонентов, не ориентируясь только на даты публикации CVE. ✅ Мы проверили июньские CVE в Axiom Spring: уязвимости в компонентах поставки устранены. Компоненты без исправлений в релиз не включаются. В статье сгруппировали все 71 CVE по компонентам, уровню опасности, механизму и другим категориям, а также заглянули в хронологию исправлений в репозиториях Spring. 🔷 Читать в Блоге

«1С» выбрала Axiom JDK Pro в качестве стандартной Java-платформы для ряда своих продуктов Дистрибутивы уже подготовлены для ряда решений: — «1С:Предприятие.Элемент» и «1С:Предприятие.Элемент Скрипт»; — «1С:Шина» и «1С:Аналитика»; — «1C» и «1С:Кабинет сотрудника». В чем преимущество для пользователя? ✅ Java идёт в комплекте с продуктом, без отдельной загрузки и настройки; ✅ Регулярные обновления безопасности и техподдержка; ✅ Работа на российских ОС, включая Astra Linux и РЕД ОС, а также Windows, macOS и Linux. Для «1С» одним из важных факторов стала надёжность платформы: предсказуемая работа Java-компонентов, регулярные обновления безопасности, техническая поддержка и контроль цепочки поставок ПО. В планах — интеграция Axiom JDK Pro и в другие решения компании. Рады, что наше сотрудничество с коллегами из «1С» расширяется! 💜 🔷 Подробнее на нашем сайте

18:44. Пятница. Пустой офис. Допивая уже остывший фильтр «Бразилия» из чашки, когда-то выигранной на одной из IT-конференций, разработчик закрывал последний тикет перед выходными. После «мелкой» правки отчёта вылезла JsonMappingException. Чтобы починить экспорт, он обновил Jackson. В Maven Central нашёлся org.fasterxml.jackson.core:jackson-databind-100-percent-safe-trust-me. «org вместо com? Ребрендинг», — решил он. На GitHub висел комментарий: «НЕ МЕРЖИТЬ». Разработчик все же нажал Resolve conversation. Смержил. CI позеленел. Прод. 03:13.  На экране телефона 24 пропущенных от SRE, тимлида, ИБ и руководителя отдела разработки (последний раз они общались на собеседовании). Теперь позеленел сам разработчик. Spring Boot при старте запустил ApplicationRunner из поддельного JAR. Тот скачал программу с чужого сервера и открыл атакующим доступ. Утекли токены и 12 млн клиентских записей. База захлебнулась, заказы встали, по API отдаёт 500. К рассвету библиотеку все же смогли удалить. Доступы отозвали, сервис подняли. Впереди — разбор утечки и часы созвонов. Что случилось с разработчиком — неизвестно. Наши дни Говорят, по пятничным вечерам дух этого разработчика бродит по пустым офисам и проверяет подозрительные библиотеки. Он не найдет покой, пока не проверит все… Но один он явно не справится: сомнительных библиотек слишком много.  Тут ему наверняка пригодится Axiom Repo: репозиторий доверенных Java-библиотек, которые наши инженеры собирают из исходников, проверяют и постоянно пополняют их каталог. 🎃 Пусть подобные истории останутся только страшилками. С наступающим хэллоуином!

Вышло октябрьское обновление Axiom JDK Мы выпустили новые сборки для шести веток: 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33 и 8u512. В релизе: 🔹 52 устранённые CVE по семейству сборок. Исправления затронули, среди прочего, сетевые и криптографические библиотеки, HotSpot и инструменты JDK. Набор патчей зависит от версии. 🔹 982 исправления и бэкпорта, включая функциональные доработки. 🔹 Для Axiom JDK Pro — обновление базы часовых поясов IANA до версии 2026b. Мы рекомендуем всегда обновляться до самых свежих версий, чтобы уровень безопасности ваших систем оставался максимально высоким. Где скачать — Axiom JDK для разработчиков доступна в личном кабинете.  — Обновления Axiom JDK Pro и Certified — на портале техподдержки. 🔷 Полный список исправлений и детали загрузки

🤖 «Меня заставили использовать OpenSpec». И что из этого вышло? Сначала AI, потом coding-агенты, теперь SDD. Знакомо? Илья Кучмин, AI DevTools Lead в Amplicode, разработчик инструментов для Java и Spring, уже настроил себе рабочий AI-harness на Claude Code, Codex и OpenIDE. Но тут сверху попросили добавить OpenSpec. Ломать то, что и так работает, не хотелось. Илья проверил на Spring-проекте, можно ли встроить OpenSpec без капитального ремонта процесса. ❓ В чём идея? Main specs описывают текущее поведение системы, а delta specs фиксируют, что нужно изменить. Дальше задача проходит три этапа: propose → apply → archive, от согласования требований до обновления спецификаций. Главный плюс: новую сессию агента можно начать без страха потерять важные решения в километрах переписки. Но тесты, отдельный worktree и код-ревью никто не отменял. А сами спецификации, признаётся Илья, пока не всегда удобно читать. В общем, OpenSpec не перевернул привычный процесс разработки, зато помог привести его в порядок. Без магии, но с пользой. 🔷 Как внедрить OpenSpec в готовый AI-harness: опыт, команды и примеры на Хабре

🎬 Видео вебинара о безопасности Spring в сети! Поддержка закончилась, а новые CVE продолжают появляться. И что теперь делать? Разобрали, почему одного мониторинга уязвимостей мало, как держать под контролем зависимости и что делать, если быстро обновить Spring не получается. Заодно обсудили, где в этой истории может помочь Axiom Spring. Получился отличный обзор рисков и способов с ними справиться. Пропустили эфир или хотите освежить главное? Отличный повод включить запись! 🌍 Смотреть в VK Видео

🎢 Java запустилась. Когда выйдет на рабочую скорость? Сервис поднят, запросы, но первые ответы медленнее обычного. При масштабировании важны и время запуска, и прогрев — период до выхода приложения на устойчивую производительность (те, кто был на Joker 2026, могли подробнее познакомиться с тем, что происходит между запуском приложения и выходом на рабочую скорость). В OpenJDK этот путь сокращают и через работу с памятью: в октябре JEP 545 и JEP 546 получили статус Targeted для JDK 28. JEP 545 предлагает ускорить получение и подготовку физической памяти в ZGC, а JEP 546 — адаптивно подстраивать размер heap под нагрузку и доступные ресурсы. Вместе с с развитием предварительной компиляции кода это помогает работать над разными составляющими старта и прогрева. Изменения готовятся для JDK 28. При тестировании будущих сборок полезно отдельно замерять запуск, задержки первых запросов и работу под устойчивой нагрузкой. Так проще понять, на каком этапе сервис выигрывает и как быстро его можно включать в нагрузку. 🔷 Подробнее

❗️ Критическая CVE-2026-91403 в Java. Что произошло? Oracle оценила проблему в JSSE на 9,1 по CVSS. У eMudhra неправильно сгенерированы закрытые ключи восьми промежуточных центров сертификации. Их можно восстановить по открытым сертификатам и выпускать поддельные TLS-сертификаты для любых доменов. Браузеры уже заблокировали эти цепочки. Но JDK по умолчанию не проверяет отзыв сертификатов, а её cacerts не всегда зависит от хранилища ОС. Если атакующий перехватит TLS-трафик, Java-клиент может принять поддельный сервер за настоящий. Это не означает, что уязвим любой Java-сервис. В списке Oracle: Java SE 8, 11, 17, 21, 25, 27 и GraalVM. Что делать? 1. Проверьте cacerts используемых JDK и контейнеров. Для JDK 11+: keytool -list -cacerts -storepass changeit | grep -E 'comodoaaaca|emsigneccrootcag3' 2. До обновления удалите два корневых сертификата или включите проверку отзыва через CRL/OCSP. Сначала протестируйте: удаление может нарушить легитимные TLS-соединения. 3. Важно: удаление корней может нарушить легитимные TLS-соединения. Альтернатива — проверка отзыва по CRL/OCSP, но её тоже нужно тестировать: возможны задержки и ошибки соединения. 4. Установите исправления поставщика и повторите проверку: обновления сертификатов ОС может быть недостаточно. Если вы клиент Axiom JDK — подробная инструкция уже у вас на почте. Мы уже готовим обновленные сборки наших продуктов. 🔷 Сообщение от Oracle | Инструкция по защите

🎬 Видео с сентябрьского Java Rock Star Meetup готовы! Вспоминаем, о чём говорили: Иван Углянский рассказал историю Project Valhalla: зачем нужны Java value-типы, почему их реализация затянулась на годы и чем интересен новый подход. Максим Козлов разобрал, как сохранить связь между требованиями и результатом в агентном SDLC, зачем нужны трассируемость и обратная связь и какую роль во всём этом играют AI-агенты. Плейлист с видеозаписями уже на площадках: 🌐 YouTube | 🌍 VK Видео

🛰 Метрики нужны, а легаси трогать нельзя. Что делать с OpenTelemetry? Знакомая история: система работает годами, новые агенты в неё не поставить, обновления случаются редко. А понимать, что происходит внутри, всё равно нужно. Кажется, OpenTelemetry должен помочь. Но тут есть подвох: вместе с мониторингом можно случайно открыть лишние точки доступа, соединить ранее изолированные сети или отправить наружу чувствительные данные. ❓ Как собрать телеметрию и не добавить проблем с безопасностью? Есть несколько рабочих приёмов: 🔹 По возможности размещать OpenTelemetry Collector отдельно от легаси. Тогда его можно обновлять, не трогая старую систему. 🔹 Оставлять только нужные подключения и маршруты передачи данных. Чем меньше открытых точек доступа, тем лучше. 🔹 Фильтровать и маскировать чувствительные данные до того, как они покинут защищённую сеть. На словах всё просто. А на практике возникают вопросы: где разместить Collector, если вынести его нельзя? Каким источникам данных доверять? И как не отправить вместе с метриками параметры оборудования? В статье разбираем обе схемы размещения Collector, сетевую изоляцию, уровни доверия к телеметрии и примеры очистки данных через transform и redaction. А ещё показываем, как подобрать меры защиты с учётом ограничений конкретной системы. 🔷 Читать статью на Хабре

Привет! Мы в Axiom JDK ищем Менеджера по работе с ключевыми клиентами в сегменте федеральных органов исполнительной власти — ФОИВ. Нам важен опыт продаж сложных IT-решений и самостоятельного привлечения новых заказчиков.  Наш идеальный кандидат: — имеет опыт продаж в IT-компании и работы с ФОИВ; — умеет самостоятельно привлекать новых заказчиков: от холодного поиска до заключения сделки; — уверенно ведёт переговоры с руководителями бизнеса и ИТ-директорами; — готов разбираться в технологических продуктах и понимает, как они решают бизнес-задачи. Что предлагаем? — работу в аккредитованной ИТ-компании; — гибкий график и гибридный формат (г. Москва, офис рядом со ст. м. Ленинский проспект); — оформление по ТК РФ, ДМС со стоматологией и страхование жизни; — бонусы по результатам работы; — возможность работать вместе с инженерами, более 25 лет создающими Java в России, и участвовать в проектах, формирующих будущее ИТ 🙋 Чувствуете, что это про вас или про ваших друзей? Тогда присылайте резюме @elizavetakushnir. Подробнее о вакансии

🎙 Предъявите ваше РБПО! Безопасная разработка — уже привычная практика или всё ещё головная боль? Что у компаний получается, а где еще предстоит найти рабочие решения?  В подкасте «За рамками кода» обсудили, как компании справляются с задачами РБПО, какие практики стоит брать на вооружение и зачем вообще контролировать весь жизненный цикл ПО. Заодно попытались заглянуть в будущее: куда движется безопасная разработка и что ждёт отрасль дальше? 🎤 У микрофона: Роман Карпов, генеральный директор Axiom JDK, руководитель Комитета по ИБ АРПП «Отечественный софт». Иван Фёдоров, первый заместитель генерального директора НПЦ «КСБ». Степан Харитонов, руководитель направления безопасной разработки и сертификации НПЦ «КСБ». 📹 Смотреть выпуск

После завершения открытой поддержки в старых версиях Spring всё ещё находят новые уязвимости. Но вот на публичные исправления рассчитывать уже не приходится. Просто следить за списком уязвимостей явно недостаточно. Нужно понимать, что именно используется в приложении, какие зависимости затронуты и как действовать, если нет возможности оперативно мигрировать на свежую версию. Как выстроить работу после окончания публичной поддержки и где здесь может помочь Axiom Spring — будем разбираться на вебинаре 20 октября. 👉 Зарегистрироваться

Привет!  Многие из вас могли замечать перебои в работе Личного кабинета разработчика Axiom JDK. Главное: сейчас всё снова работает в штатном режиме. Мы восстановили работу Личного кабинета и всех его функций. Если вы столкнётесь с какими-либо проблемами, лучше сразу обратиться в службу поддержки support@axiomjdk.ru или завести тикет в GitLab. Так мы сможем помочь вам наиболее оперативно.  Благодарим за терпение и приносим извинения. Команда Axiom JDK 💜

📄 Как проверить 7 000 000 строк JDK? Мы внедрили Svace и платформу Svacer от ИСП РАН в процесс анализа кодовой базы Axiom JDK. Задача была не просто добавить ещё один SAST. Кодовая база JDK огромная, а требования к безопасной разработке и сертификации растут. Поэтому нужен инструмент, который умеет глубоко разбирать межпроцедурные связи и нормально работает на таком масштабе. 📊 Результат  Svace прогнал около 7 млн строк кода, а команда обнаружила и исправила примерно 1,2 тыс. дефектов. При этом одним анализатором дело не ограничилось. Svace стал основным инструментом глубокого анализа, а другие SAST и open-source-линтеры дополняют его: разные движки находят разные классы проблем. Отдельная история — разбор тысяч предупреждений. Для этого используем Svacer и ML-классификацию: сейчас один разработчик в среднем проверяет около 50 срабатываний в день. 🔷 О том, как статический анализ стал частью процесса разработки JDK, рассказали в Блоге.

🏎 Постквантовая криптография в JDK становится быстрее В JDK уже есть ML-KEM и ML-DSA, но их базовая Java-реализация рассчитана прежде всего на переносимость. В JDK 28 HotSpot начинает точечно подменять самые тяжёлые операции оптимизированным машинным кодом под конкретную архитектуру. 📈 Существенный ли прирост?  В опубликованных тестах ускорение местами доходит до 218% — то есть операция выполняется примерно в 3,18 раза быстрее Java-only версии. В этих алгоритмах много повторяющихся вычислений над полиномами, которые хорошо ложатся на векторные инструкции и аппаратное ускорение.  Для команд, которые уже примеряют постквантовую криптографию, это снижает её вычислительную цену: генерация ключей, инкапсуляция и работа с подписями меньше нагружают процессор.  Но магии нет: HotSpot использует такую оптимизацию только там, где её поддерживает платформа. Поэтому финальные цифры всё равно стоит замерять на своём железе. 🔷 Подробности

🔒 В Spring LDAP обнаружили CVE-2026-41720, из-за которой приложение при определённых условиях могло принять пустой пароль за успешную аутентификацию. Но это не значит, что без пароля можно было войти в любой LDAP. Для эксплуатации требовалось совпадение ряда условий:  • уязвимая версия Spring LDAP; • атакующий знал существующее имя пользователя; • пустой пароль или null; • LDAP-сервер разрешил unauthenticated bind; • приложение приняло ответ и создало пользовательскую сессию. Фикс уже выпустили: • Spring LDAP 4.0.0–4.0.3 → 4.0.4; • Spring LDAP 3.3.0–3.3.7 → 3.3.8. ❓ Это все понятно. А что делать? В первую очередь — обновиться. Затем проверить саму конфигурацию: нужен ли вообще unauthenticated bind и отклоняет ли приложение пустые пароли до обращения к LDAP. Если нельзя исключить, что уязвимость уже эксплуатировали, тогда начинается уже не патчинг, а расследование: стоит проверить журналы аутентификации и действий пользователей, завершить подозрительные сессии и при необходимости временно ограничить LDAP-вход. После обновления отдельно прогоните вход с пустым паролем — система должна ответить отказом. 🔷 Подробный разбор

🖥 JDK 27 меняет сразу два runtime-дефолта, которые могут повлиять на поведение сервиса даже без правок в коде 1. Compact Object Headers теперь включены по умолчанию. На типичной 64-битной HotSpot-конфигурации заголовок объекта уменьшается с 12 до 8 байт. 2. G1 теперь GC по умолчанию вообще везде, в том числе в небольших контейнерах и однопроцессорных средах, где раньше JVM могла выбрать Serial GC. С компактными заголовками выигрыш особенно заметен там, где в heap много мелких объектов: в одном из замеров SPECjbb2015 расход памяти снизился на 22%, а CPU — на 8%. С G1 нюанс другой: на небольших конфигурациях могут сократиться паузы, нагрузка на CPU и потребление памяти. Поэтому переход на JDK 27 лучше проверять не одним общим бенчмарком. Снимите базовые метрики на текущей версии, а затем отдельно сравните новые дефолты: Compact Object Headers можно временно отключить, а GC — выбрать явно. Так будет понятно, что именно изменило профиль приложения. 🔷 Источник