Сегодня — Java 30 лет 🎂

Опубликовал большую статью на Хабре — о том, как развивалась Java, что происходило внутри JVM, и куда всё это движется дальше.

📌 В статье:
— История версий Java: от Playground до Java 24
— Эволюция языка
— Как работает JVM и почему HotSpot такой «горячий»
— Проекты OpenJDK: Leyden, GraalVM, CRaC — зачем они нужны и как меняют подход к производительности
— И главное — как Java готовится к будущему

🧠 Подойдёт всем, кто пишет на Java или просто хочет понять, как устроена одна из самых влиятельных технологий в мире разработки.

📖 Читать статью на Хабр

#java_hub_history

🚀 Двоичная Java: CDS, CRaC и AOT для ускорения запуска и прогрева JVM

🔍 Миф №1 о Java:

> «Java — это медленно»

Да, лет 20 назад это могло быть правдой. Но JVM с тех пор прошла огромный путь.

В классическом варианте Java-байткод исполняется через интерпретатор — по сути, цикл со switch-case, где инструкции переводятся на лету. Это действительно не быстро.

📈 Первый прорыв — JIT-компиляция (Just-in-Time): часто вызываемые методы начали компилироваться в машинный код во время выполнения. Это дало солидный прирост производительности.

💡 Но на этом оптимизации не остановились. Сегодня в арсенале JVM есть:

* CDS (Class Data Sharing) — сериализация внутренних представлений классов, чтобы ускорить их загрузку из архива.

* CRaC (Coordinated Restore at Checkpoint) — снятие снепшота уже «прогретой» JVM, чтобы потом мгновенно восстановить её в этом состоянии.

* AOT (Ahead-of-Time compilation) — компиляция Java-приложения в нативный бинарник заранее, без участия JIT в рантайме.

🧪 А на подходе ещё Project Leyden, который обещает сделать JVM по-настоящему предсказуемой и «запускаемой с кнопки» — благодаря condensers и training runs.

🎤 Обо всём этом я рассказывал на HighLoad++ 2024. Видео пока не выложили, но мои друзья из Axiom JDK подготовили текстовую версию доклада 📄

📎 Читайте: «Двоичная Java: CDS, CRaC и AOT для ускорения запуска и прогрева JVM»

#java_hub_jvm

🔁 Saga Pattern в микросервисной архитектуре: можно ли обойтись без распределённых транзакций?

Выступил на онлайн-встрече "Книжного клуба .rar" — Telegram-сообщества для Java-разработчиков, где регулярно обсуждают профессиональную литературу, технологии и устраивают встречи с практикующими инженерами 👉 @point_rar

В этот раз разбирали реализацию паттерна Saga на Java с использованием Temporal

Демо-проект на GitHub - https://github.com/RustamKuramshin/spring-boot-saga-pattern-example

Презентация мини-доклада тут

📦 Что такое Saga и зачем она нужна?

В распределённой системе аннотация Transactional не работает между сервисами. А бизнесу всё ещё нужно "всё или ничего":
если деньги списались, товар должен быть зарезервирован и доставлен. Если нет — откатить всё назад.

Saga — это паттерн, который разбивает такую бизнес-транзакцию на цепочку локальных транзакций, и если что-то идёт не так, вызывает компенсационные действия (например, вернуть деньги).

🧩 Два способа реализовать Saga

🔸 Оркестрация
Один сервис (оркестратор) управляет всей логикой: вызывает шаги, следит за результатами, вызывает компенсации.
➕ Централизованно, легко отлаживать
➖ Меньше изоляции между сервисами

🔸 Хореография
Сервисы реагируют на события (event-driven): "платёж прошёл" → "резервируй товар" → "создай доставку".
➕ Слабо связанная архитектура
➖ Сложно проследить цепочку событий и откатов

⚙️ В Temporal реализация Saga — это workflow, в котором бизнес-процесс описывается обычным Java-кодом.
Он:
- сохраняет состояние каждого шага (event sourcing),
- автоматически повторяет activities при сбоях,
- управляет timeouts и compensation logic,
- отделяет workflow (координацию) от activity (действий).

Например, просто пишешь:

activities.makePayment();
saga.addCompensation(activities::cancelPayment);

А Temporal сам заботится о повторяемости, масштабировании и отказоустойчивости.

Если интересно больше узнать про Temporal, рекомендую посмотреть доклад Петра Сальникова с JPoint. Мне повезло присутствовать в зале на самом докладе. В дискуссионной зоне Петр ответил на множество вопросов как раз в тот период, когда мне нужно было самому разбираться с Temporal.

#java_hub_patterns

Как не облажаться с типами данных в PostgreSQL

Опубликовал перевод главы из "PostgreSQL Mistakes and How to Avoid Them"

Недавно вышла книга PostgreSQL Mistakes and How to Avoid Them — своего рода «коллекция грабель» для разработчиков и администраторов. Автор — Джимми Анджелакас, архитектор систем и активный участник PostgreSQL-сообщества. Он собрал десятки реальных ошибок из продакшн-проектов: от неочевидных тонкостей конфигурации до подводных камней SQL и выбора типов данных.

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

Например:

- timestamp without time zone — источник боли при расчётах с часовыми поясами (и переходом на летнее/зимнее время).

- money — тип, который не хранит валюту и округляет в минус (буквально).

- char(n) и varchar(n) — не экономят место, а индексам только мешают.

- serial — привет из прошлого века, лучше использовать identity-колонки.

В этой главе подробно разбираются проблемы, которые в реальных системах могут оборачиваться часами отладки и багами, которые «не воспроизводятся». Особенно интересно, как наивный timestamp приводит к неправильным интервалам из-за перехода на зимнее время — и почему timestamptz лучше почти во всех случаях.

Если вы проектируете схемы БД, пишете SQL-запросы или просто работаете с PostgreSQL в проде — эта глава точно будет полезной. Причём независимо от стека: будь вы Java-разработчиком, Python-разработчиком или пишете на Go — с базой данных всё равно общаться придётся.

📖 Читаем перевод на Хабре:
https://habr.com/ru/articles/923572/

🤖 Встречайте Koog — новый AI-фреймворк от JetBrains

Рустам Курамшин, эксперт сообщества Spring АйО, подготовил пост про новый AI-фреймворк от JetBrains – Koog.

AI-агенты — это не фантастика. Это новый уровень взаимодействия с LLM, где модели не просто болтают в чате, а действуют: они умеют вызывать внешние инструменты, планировать, запоминать контекст, адаптироваться и выполнять сложные задачи почти без участия человека.

Эти агенты становятся ключевым компонентом современных систем: от помощников в IDE и CI/CD пайплайнах до интеллектуальных обработчиков в бизнес-приложениях.

JetBrains представили Koog — open source фреймворк для разработки AI-агентов на Kotlin.

Что такое Koog?

Koog — это Agentic AI фреймворк, написанный полностью на идиоматичном Kotlin. Он позволяет создавать AI-агентов, которые:

- запускаются локально без внешних зависимостей
- умеют вызывать инструменты и API
- обрабатывают сложные пайплайны через графовые сценарии
- поддерживают мультимодели (OpenAI, Anthropic, Google, Ollama и др.)
- работают на JVM и JS (за счет Kotlin Multiplatform)

Koog можно использовать как для простых агентов “вопрос-ответ”, так и для построения сложных, многосоставных систем с устойчивой памятью, сжатой историей, потоковой обработкой ответов и гибкой трассировкой.

До недавнего времени экосистема Java не имела по-настоящему удобных, нативных инструментов для работы с AI-агентами, возможно кроме Spring AI в составе Spring Framework.

Пример использования минимального AI-агента в Koog:

fun main() = runBlocking {
    val apiKey = System.getenv("OPENAI_API_KEY")
    
    val agent = AIAgent(
        executor = simpleOpenAIExecutor(apiKey),
        systemPrompt = "Ты - очень полезный ассистент-помошник",
        llmModel = OpenAIModels.Chat.GPT4o
    )

    val result = agent.run("Привет! Чем можешь помочь?")
    println(result)
}

Koog — это, возможно, первый шаг к тому, чтобы писать LLM-based приложения просто на Kotlin без лишних зависимостей.

Как потестить Koog:

Репозиторий: https://github.com/JetBrains/koog

Документация: https://docs.koog.ai

Быстрый старт: https://docs.koog.ai/single-run-agents/

💬 Как вам Koog? Делитесь мнениями в комментариях! 👇

Смешно. Наткнулся на Telegram-бота для анализа тг-каналов. Считывает посты и выносит вердикт 😅

Вот что написал в режиме Roast Analysis 😁

📊 Channel Analysis Results by @ScratchAuthorEgoBot

🎯 Channel: @java_hub_official

🔥 Roast Analysis:

Слушай, чувак, ну вот ты опять, да? Канал создан, и сразу поток "Ява – это жизнь, Ява – это боль, Ява – это…". Мы поняли, ты джавист до мозга костей. "Java Boys"? Серьезно? Вы там что, в кожаных куртках и на байках по выходным катаетесь, распевая гимн Spring Boot? Или это просто самое креативное название, что пришло в голову куче чуваков, которые ночами гуглят, почему их null не такой уж null?

Твои посты, конечно, информативные, спору нет. Но иногда кажется, что ты пишешь их не для живых людей, а для искусственного интеллекта, которого тренируешь на знание всех аспектов JVM. "От Playground до Java 24", "JIT-компиляция", "Project Leyden"... Мне уже дурно от одной мысли. Можно хоть один пост про то, как ты бургер ел, а не про то, как байткод оптимизировался?

А эти твои хакатоны – "готов мало спать на протяжении нескольких дней"! Дружище, твоя печень уже, наверное, звонит в профсоюз и просит отпуск. Ты вообще знаешь, что такое "выходные"? Это когда ты не пытаешься за 48 часов запихнуть весь Интернет в Spring Boot-приложение. И "побеждали Сбер, ВТБ, МТС" – ну да, мы уже поняли, ты – хакатон-Терминатор. Мы же все просто лузеры, которые не знают, как правильно настроить temporal.io, чтобы он не рухнул от одного чиха.

И эта твоя любовь к Хабру! Каждый раз, как будто новую библию выпускаешь. "Опубликовал большую статью", "Перевел главу из книги"... Мы уже ждем твой подкаст с названием "Как я провел свои выходные, написав очередную статью на 10 тысяч символов о том, почему null – это плохо". Да, мы знаем, null – это миллиарднодолларовая ошибка. А ты что, прямо вот так и веришь, что Google не способен решить проблему с null? Или ты просто хотел покрасоваться, что "мы, Java-разработчики, не удивлены"? Ну да, вы же самые умные, вы-то точно не облажаетесь.

Короче, пора тебе уже признать, что ты не просто разработчик, ты – Java-гуру, который дышит байткодом и спит с IntelliJ IDEA в обнимку. Но иногда хочется, чтобы ты просто выдохнул, выключил свой MCP-сервер и рассказал что-нибудь, что не заставит мой мозг компилироваться в машинный код. А то от твоих постов можно получить переполнение стека в собственной голове.