⏱ Часы Лампорта

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена.

Сервисы пишут события, стримы обрабатываются в реальном времени, данные реплицируются по датацентрам. И почти в каждом таком сценарии возникает фундаментальный вопрос:

Как понять, что произошло раньше, а что позже, если глобального времени не существует?

Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах.

📚 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1005934/

👩‍💻 Cursor теперь доступен в IDE JetBrains

Cursor пришел в IDE JetBrains: IntelliJ IDEA, PyCharm, WebStorm и другие теперь подключают его через Agent Client Protocol (ACP). А это значит, что работать с агентом можно прямо в JetBrains-IDE.

Cursor ACP дает выбор модели под задачу: OpenAI, Anthropic, Google и модели Cursor. Под каждую модель у Cursor своя агентная обвязка, чтобы держать качество и скорость.

Как включить:

– установить Cursor ACP из ACP Registry
– авторизоваться существующей учеткой Cursor

Плагин является бесплатным для пользователей на платных тарифах Cursor.

🔗 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1006764/

🔓 Copyright больше не защищает ваш код

Я тут поймал себя на мысли про ИИ-агентов и open source. Сразу уточню: речь не про проблему обучения ИИ на коде под лицензией.

Не знаю, как кодят другие, но мой текущий процесс выглядит примерно так:

• Сначала собираю спецификацию (конечно, с помощью ИИ);
• По спецификации делаю план реализации;
• План отдаю ИИ-агенту.

В плане есть:

• гейты перехода между этапами;
• тесты;
• definition of done.

Дальше агент просто проходит по плану. Конечно, я сильно упрощаю, но общий принцип понятен.

И вот здесь возникает интересный момент.

Спецификацию можно собрать практически из чего угодно.

Например, из проекта под «заразной» лицензией вроде GNU GPL.

Можно внимательно изучить проект и написать подробную спецификацию:

• какие есть модули;
• как они взаимодействуют;
• какие алгоритмы используются;
• какие интерфейсы между компонентами.

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

Дальше по этой спецификации другой ИИ-агент составляет план реализации, и запускается разработка. Через несколько итераций получается новый проект:

• он работает;
• код другой;
• структура файлов может быть другой;
• даже язык программирования может быть другим.

Но по сути это та же система, просто переписанная по спецификации.

Фактически получается что-то вроде автоматизированной clean-room реализации.

И вот тут возникает вопрос:

Защищает ли open-source лицензия от такого сценария?

Кажется, что нет. Потому что copyright защищает:

• конкретный код;
• конкретную реализацию.

Но не защищает:

• идеи;
• алгоритмы;
• архитектуру системы.

ИИ просто делает переход от чужой архитектуры к новой реализации очень дешёвым.

Раньше clean-room реализация требовала команды инженеров. Теперь это можно провернуть с помощью одного человека и пары ИИ-агентов (умножить на X).

Поэтому у меня появилась мысль:

Возможно, если кто-то действительно хочет защитить open-source проект от подобного «переизобретения», одной классической лицензии уже недостаточно.

Потому что лицензии регулируют копирование кода, а не пересборку системы по её описанию.

Утекшие исходники

Но это еще не все. Представим, что, не дай бог, исходники вашего закрытого ПО утекли в открытый доступ. Конечно же, никто в здравом виде не будет разворачивать ваш сервис у себя. Но теперь у любого есть армия неутомимых воинов за 100$-200$ в месяц, которые под чутким руководством могут скопировать ваш сервис так, что никто не придерется.

Возможно, ИИ просто подсветил старую юридическую проблему, которая раньше была менее заметна.

❓ Интересно, обсуждалось ли это уже где-нибудь.

🧩 Разница между параллельными и распределёнными вычислениями

Ускорение работы приложения можно получить двумя способами: распараллелить работу между ядрами одного компьютера или разнести ее по нескольким машинам.

Параллельные вычисления живут внутри одного узла: части задачи выполняются одновременно на CPU-ядрах, нескольких процессорах или ускорителях GPU/TPU.

Параллелизм бывает по задачам и по данным (одна операция над разными блоками), а также на уровне инструкций (конвейеризация, суперскалярность) и битов. Обмен данными чаще происходит через общую память и локальный IPC, поэтому задержки ниже.

Распределенные вычисления делят в свою очередь работу между автономными узлами по сети. Данные передают сообщениями или через RPC, координация сложнее, зато масштабирование обычно проще: добавил узлы - выросли вычисления и хранилище. Часто закладывают отказоустойчивость: репликация, резервирование, обнаружение ошибок.

🔗 Подробности в нашей статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1008990/

Для JetBrains IDE вообще есть нормальный AI без проблем в РФ?

Периодически в @spring_aio_chat и на Хабре прилетают вопросы про то, какие сейчас есть варианты использования ИИ внутри IDE.

Один из вариантов – Kodacode.

Работает:
— в OpenIDE и JetBrains IDE
— в VS Code
— и даже в CLI

Что кажется наиболее полезным:
— агентный режим: без него от ИИ-помощника смысла не так много
— доступ к разным моделям: GLM, Gemini, DeepSeek, и другие
— работает без танцев с VPN и оплатами: у многих это сейчас главный стоп-фактор для AI-инструментов
— есть бесплатная модель: хватает для повседневных задач

📚 Подробнее про Koda для JetBrains IDE читайте на Хабр: https://habr.com/ru/companies/koda/articles/986976/

👩‍💻 JEP 524 в JDK 26 — второй preview PEM API.

Наконец-то работа с PEM в Java становится похожа на API, а не на набор ручного парсинга, Base64 и странных телодвижений.

Справка: PEM или Privacy-Enhanced Mail - это текстовый контейнер для криптографических данных. Проще говоря – это способ хранить или передавать ключ, сертификат или другой crypto-объект не в бинарном виде, а в текстовом.

Раньше с PEM работали так:

String pem = "-----BEGIN PUBLIC KEY-----\n"
        + Base64.getMimeEncoder(64, "\n".getBytes())
                .encodeToString(publicKey.getEncoded())
        + "\n-----END PUBLIC KEY-----";

А в обратную сторону, но уже с ручной нормализацией PEM, Base64-декодированием и KeyFactory:

String normalized = pem
        .replace("-----BEGIN PUBLIC KEY-----", "")
        .replace("-----END PUBLIC KEY-----", "")
        .replaceAll("\\s", "");

byte[] der = Base64.getDecoder().decode(normalized);

PublicKey key = KeyFactory.getInstance("EC")
        .generatePublic(new X509EncodedKeySpec(der));

По факту PEM в Java долгое время был не отдельным API, а набором низкоуровневых шагов, которые разработчик собирал руками.

А теперь это выглядит так:

var encoder = PEMEncoder.of();
String pem = encoder.encodeToString(keyPair);

var decoder = PEMDecoder.of();
KeyPair decoded = decoder.decode(pem, KeyPair.class);

То есть ключевую пару можно закодировать в PEM и декодировать обратно буквально в несколько строк.

Во втором preview:
— PEMRecord переименовали в PEM
— добавили decode()
— расширили поддержку KeyPair и PKCS8EncodedKeySpec
— упростили шифрование через EncryptedPrivateKeyInfo

А так, как все это дело еще в preview, не забываем использовать --enable-preview.

❓ Минус еще один кусок криптографической копипасты из Java-кода. PEM в Java постепенно перестает быть унылым?

#видеозаписи

Открываем новую видеозапись доклада:
Михаил Поливаха — Spring AOT: кодогенерация на стероидах

😉 YouTube | 📺 VK Видео

🗑️ Изменения в G1/Parallel/Serial GC в JDK 26

JDK 26 выходит уже совсем скоро. Тем временем в GC закрыли около 380 задач (почти в 2 раза больше, чем в прошлом релизе), но в этот раз акцент сместился с больших фич в пользу практичных доработок.

Главное для всех сборщиков: нормальный учет CPU GC. Теперь считают не только stop-the-world паузы, но и конкурентную работу и дедупликацию строк. Можно посмотреть через лог cpu=info при завершении VM, обновили Hsperf-счетчики, есть доступ из кода. Плюс новый JFR-ивент с деталями по string dedup.

JEP 516: Aot Cache стал независим от выбранного GC и опций VM. Включение через опцию -XX:+AOTStreamableObjects.

G1 получил самые заметные улучшения: JEP 522 уменьшает синхронизацию между GC и приложением (цель - увеличить throughput). Еще: целевое использование CPU G1 по умолчанию снижено с 8% до 4%, добавили важнейший флаг UseGCOverheadLimit.

Комментарий от Михаила Поливаха:

Важно и то, что HotSpot GC команда в Oracle смотрит в сторону Automatic Heap Sizing. На эту темы было много шума на Redit и не зря. Поговорим об этом на подкасте.

📎 Подробнее в статье: https://habr.com/ru/companies/spring_aio/articles/1010904/

👩‍💻 Привет, Java 26!

Встречаем 26 версию нашего любимого языка программирования.

Что самое заметное:

☑️ HTTP/3 в HttpClient (JEP-517)
Теперь java.net.http.HttpClient умеет HTTP/3. Для client-side кода это хороший апгрейд: меньше магии, ближе к современному вебу из коробки.

☑️ G1 стал быстрее по throughput (JEP-522)
В Java 26 уменьшили синхронизацию между application threads и GC threads. Для тех, кто сидит на G1 по умолчанию, это может дать вполне практичный прирост без смены GC и без шаманства с флагами.

☑️ Structured Concurrency все еще с нами (JEP-525)
Уже шестой preview, но направление давно понятно: многопоточность в Java все сильнее движется к более внятной модели управления связанными задачами, отменой и ошибками. Для сервисного кода — очень правильный вектор.

☑️ Pattern Matching расширили на примитивы (JEP-530)
instanceof, switch, patterns — теперь и для примитивных типов. Пока preview, но курс очевиден: язык становится ровнее и выразительнее.

☑️ Vector API продолжает дозревать (JEP-529)
Уже 11-й incubator. Для high-performance сценариев, аналитики и местами AI/inference должно быть полезным.

☑️ Leyden-путь продолжается (JEP-516)
AOT object caching теперь работает с любым GC, включая ZGC. То есть разговор про быстрый startup/warmup Java-приложений становится еще менее "на словах".

☑️ final начинают защищать всерьез (JEP-500)
Добавляются предупреждения на deep reflection, который мутирует final-поля. Java продолжает двигаться к integrity by default. Если у вас есть старые хаки через reflection, то самое время проверить, не пора ли их вычищать.

☑️ Applet API удалили окончательно (JEP-504)
Да, в 2026 это уже скорее символический жест. Но хороший, так платформа продолжает избавляться от давно мертвого наследия.

А ещё:

🔘Process теперь AutoCloseable
🔘появился UUIDv7 через UUID.ofEpochMillis(...)
🔘Javadoc получил dark theme
🔘Thread.stop() удален окончательно
🔘виртуальные потоки стали аккуратнее вести себя в одном неприятном сценарии с class initialization

Итог

Пожалуй, нас не порадовали “кричащими” фичами уровня смены эпохи, но есть много сильных улучшений в том, что реально влияет на повседневную разработку: сеть, GC, concurrency, безопасность, startup и чистка платформы от старого балласта.

📎Полный список изменений тут: https://jdk.java.net/26/release-notes

❓Кто уже успел посмотреть JDK 26 — что зацепило больше всего?

🌎 О размерах пула соединений

Есть такой момент, что большой пул часто ухудшает отклик: БД упирается в ограниченные ресурсы (CPU, диск, сеть), начинается лишняя конкуренция и накладные расходы, latency растет.

Действительно, ребята из Oracle в своей демке обычным уменьшением пула снизили время ответа примерно со 100 мс до 2 мс.

Сама практика такая: пул держат небольшим. Потоки приложения запрашивают свободное соединение в пуле, либо ждут его появления там. Это нормальная очередь, которая защищает БД от перегруза.

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

📎 Подробнее в статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1011770/