Часть 1. Java не участвовала в ИИ-гонке. Она была на работе

Пока одни спорят, что Python — единственный язык для искусственного интеллекта, другие тихо строят ИИ-системы там, где они действительно нужны: в банках, телеком-сетях, страховых и логистических платформах. И делают на Java. В 2026 году это уже не компромисс, а осознанный выбор, и у него есть цифры за спиной.

По данным исследования Azul, 62% опрошенных компаний используют Java для создания ИИ-функциональности. Это на 12 процентных пунктов больше, чем годом ранее, когда показатель составлял 50%. Тренд устойчивый, и он говорит о простой вещи: ИИ перестал быть игрушкой дата-сайентистов и стал функцией продукта. Причина прагматична: Java несёт на себе нагрузку критичных систем. В JVM есть отлаженная модель памяти, пулы потоков, виртуальные потоки, сборка мусора, средства наблюдаемости и зрелые фреймворки. Python силён в исследованиях и прототипах, но когда модель нужно вызвать из транзакционного контура с SLA, аудитом и шифрованием, Java оказывается ближе к продакшену. В 2026 году ИИ-функция — это не отдельный скрипт, а ещё один сервис в архитектуре, и он должен жить по тем же правилам, что и остальные.

А функции продукта живут не в ноутбуке с визуализацией. Они живут в транзакционных системах, в микросервисах, в очередях сообщений. В том стеке, который десятилетиями написан на Java. Когда банк хочет встроить LLM в мобильное приложение, он не переписывает бэкенд на Python — он добавляет зависимость в существующий Spring Boot-проект. Банк может добавить LLM для суммаризации обращений в контакт-центре, телеком — для диагностики сетевых аномалий, страховая — для разбора claim’ов, логистика — для планирования маршрутов. Во всех случаях данные уже лежат в Java-сервисах, а выносить их в отдельный Python-слой дорого, долго и рискованно с точки зрения комплаенса. Поэтому LLM вызывается из того же Spring Boot-приложения, где уже есть бизнес-логика, права доступа и аудит.

Ещё в 2024 году это было больно. Java-разработчик, захотевший вкрутить LLM в приложение, чувствовал себя неуютно: Python-коллеги вовсю использовали LangChain, а Java-экосистема предлагала в лучшем случае REST-обёртки над чужими API. За два года ситуация изменилась радикально.

LangChain4j — не порт Python-библиотеки, а самостоятельная Java-библиотека, спроектированная вокруг Java-конвенций с нуля. Она поддерживает интеграцию с более чем 20 провайдерами LLM и встраивается в Spring Boot и Quarkus через стартеры. Она закрывает не только чат: embeddings, vector stores, RAG, tool calling, agents, memory, structured output. Рядом развиваются Spring AI, Quarkus LangChain4j, Micronaut, Embabel, Jlama, Deep Java Library и ONNX Runtime Java. Векторные базы — pgvector, Redis, Elasticsearch, Milvus, Qdrant — подключаются через общие абстракции. Появляется поддержка MCP, что позволяет Java-агенту безопасно ходить в инструменты и данные.

Spring AI 2.0 вышел в статусе GA 29 июня 2026 года и принёс то, что Spring-разработчики ждали больше всего: ChatClient API как базовую абстракцию для работы с LLM, поддержку виртуальных потоков, GraalVM Native Image и observability с помощью Micrometer. Если ваша команда уже пишет на Spring Boot, порог входа в ИИ-разработку падает до уровня «добавить зависимость». ChatClient API, Advisors, function calling и structured output позволяют описывать ИИ-сценарии декларативно. Виртуальные потоки снимают боль блокирующих вызовов LLM, GraalVM Native Image ускоряет старт, а Micrometer даёт метрики по токенам, задержкам и стоимости. Плюс Spring Security, OAuth2 и Testcontainers — то, чего часто не хватает быстрым прототипам.

Вывод простой и неудобный для тех, кто считает Java «языком прошлого»: пока индустрия обсуждала, кто круче в экспериментах, Java тихо стала языком, на котором ИИ доезжает до продакшена. И это только начало, потому что дальше начинается самое интересное: агенты, которые умеют отвечать за свои решения. Java с её строгой типизацией, зрелым CI/CD-процессом и управлением зависимостями может дать таким агентам то, что нужно продакшену: предсказуемость, контроль и наблюдаемость.