Джава Ван Лав

null, который положил Google Cloud Platform 😱 Вокруг только и разговоров, что о post-mortem недавнего инцидента в Google Cloud 👩‍💻 12 июня Google Cloud прилёг. На несколько часов так прилёг. Упали App Engine, BigQuery, Cloud SQL, IAM, Cloud Run — и ещё с десяток ключевых сервисов. А всё началось с Null Pointer Exception 29 мая в компонент GCP под названием Service Control добавили новую ветку логики для проверки квот. Код попал в прод, но не активировался — требовалась определённая конфигурация политики, которая на тот момент ещё не существовала. 12 июня эти политики всё-таки были задействованы. В Spanner (распределённая база данных от Google) записались данные с пустыми полями. Service Control начал использовать новую логику, где не было защиты от null. И началось: сервис стал падать в каждом регионе. Ошибки 503 прокатились по всем зависимым API. Глобальная катастрофа — за пару секунд. Каковы корневые причины? - Null Pointer Exception в новой логике квот. - Отсутствие feature flag’а — код сразу пошёл "в бой", без фазового включения. - Нет fallback-механизма (fail-open). - Не было адекватного тестирования — критическая ветка не активировалась до продакшна. - Мгновенная глобальная репликация метаданных — баг разлетелся по всему миру за секунды. Кто бы мог подумать, что в 2025 году глобальный сервис положит банальный NPE. Мы, Java-разработчики, к сожалению, не удивлены null — это старая боль JVM. Известный billion-dollar mistake, как его однажды окрестил Тони Хоар. За десятилетия было много попыток уменьшить ущерб от null: - Kotlin с его строгой null safety. - Optional в Java 8. - Проект JSpecify, который пытается ввести строгую спецификацию аннотаций nullability. - Черновик JEP'а про Nullable-типы на уровне JVM. А ведь в Go (на нём пишут в Google), несмотря на переименование null в nil, проблемы всё те же, хе-хе 👩‍💻 Крах Google Cloud — это textbook fail в области feature toggle практик. Если бы новая логика была обёрнута в фичефлаг с постепенны

👩‍💻 GitHub запускает MCP-сервер ИИ-агенты сегодня — это не просто тренд, а новая парадигма взаимодействия с инструментами разработки. Вместо того чтобы ограничиваться подсказками по коду, современный AI получает полномочия действовать как полноценный участник процесса: анализировать проект, создавать PR'ы, запускать CI, вести дискуссии в issue и автоматизировать рутину. Для этого нужна инфраструктура. И вот GitHub выкатывает один из главных строительных блоков — официальный GitHub MCP-сервер. 📌 Что такое MCP? MCP (Model Context Protocol) — это стандарт для интеграции LLM-агентов с внешними инструментами. Он описывает, как агент может обращаться к API, какие действия доступны и в каком контексте. MCP-сервер предоставляет весь необходимый интерфейс, чтобы LLM могла, например, создать issue, обновить pull request, запросить ревью или найти баг в коде. Иными словами, MCP-сервер превращает LLM в разработчика, способного действовать. 📦 Что внутри GitHub MCP-сервер официально доступен как в виде локального Docker-контейнера, так и как хостинг-сервис от GitHub — с полноценной поддержкой OAuth 2.0, SAML и автоматическим обновлением. Возможности: - Полный доступ к GitHub API через безопасную прослойку. - Управление репозиториями, PR, issue, CI/CD, пользователями, кодом и даже секретами. - Возможность фильтровать доступные инструменты (например, включить только работу с PR и Actions). - Поддержка read-only режима — чтобы LLM-агент был только наблюдателем. - Встроенная динамическая загрузка инструментов — чтобы модель не путалась в избыточных возможностях. 🛠 Как использовать? Подключение в 👩‍💻 VS Code (начиная с версии 1.101) буквально в пару кликов. После этого — активируйте Agent Mode, и LLM сможет работать с MCP напрямую. Интеграция с другими IDE и MCP-хостами через JSON-конфигурацию. Можно использовать в своих проектах для создания кастомных агентов: например, AI-помощник по ревью кода. 💡 Перспективы Большинство современных AI-агентов для кодинга всё ещё

🏆 Вся правда о хакатонах в России от Java Boys и Jmix 🌐 Смотреть на YouTube 🌍 Смотреть на VK Видео Что на самом деле происходит на хакатонах? Как собрать сильную команду, не слиться на следующий день и дойти до победы? Хакатоны - это одно из моих увлечений в разработке. То ради чего я готов мало спать на протяжении нескольких дней, пока мы готовим очередной невероятный проект 😅 Моя команда называется "Java Boys". Сложно придумать другое название, когда тебя окружают один джависты. И вот мы наконец сняли подкаст про хакатоны с Дмитрием Черкасовым, DevRel-ом команды Jmix, отечественного java-фреймворка для быстрой разработки, основанного на Spring Boot. На подкасте мы обсудили: — как выбрать задачу, чтобы не перегореть и успеть к дедлайну — почему Jmix стал нашим ключевым инструментом на хакатонах — как организована работа внутри нашей команды — какие проекты мы делали и почему они побеждали — и что нужно, чтобы вам тоже начать побеждать Много живого опыта, немного самоиронии и полезные советы от тех, кто выигрывал хакатоны Сбера, ВТБ, МТС и других. Если интересна внутренняя кухня хакатонов — обязательно смотрите!

☕️ Вышла Jakarta EE 11 — крупнейшее обновление платформы с упором на Java 21, облачные приложения и производительность Если вы давно в Java — вы наверняка помните Java EE. А если только входите в энтерпрайз-разработку — скорее всего, уже слышали про Jakarta EE. Jakarta EE — это набор спецификаций и стандартов для разработки масштабируемых, надёжных и переносимых серверных приложений на Java. Это то, что стоит за большинством Java-серверов, включая GlassFish, WildFly, Open Liberty, Payara, WebLogic и многие другие. Что входит в Jakarta EE? Jakarta EE — это не одна технология, а экосистема. Вот лишь часть ключевых спецификаций: - Jakarta Servlet — фундамент веб-приложений на Java. - Jakarta RESTful Web Services (JAX-RS) — для создания REST API. - Jakarta Persistence (JPA) — ORM-решение для работы с базами данных. - Jakarta Contexts and Dependency Injection (CDI) — современная DI-модель. - Jakarta Security, Jakarta Transactions, Jakarta Messaging (JMS) — всё, что нужно для построения зрелых корпоративных систем. С 2017 года, после передачи Java EE под крыло Eclipse Foundation, проект получил второе дыхание. Так появился бренд Jakarta EE — с открытым процессом разработки, поддержкой крупных вендоров и фокусом на совместимость, эволюцию и инновации. Что нового в Jakarta EE 11? 26 июня вышел Jakarta EE 11 — самый свежий релиз платформы. Что в нём интересного? Jakarta Data — новая спецификация, упрощающая работу с хранилищами данных: Репозитории по аналогии с Spring Data (CrudRepository, Pagination, query-методы). Упрощение API: - Удаление Managed Beans - CDI теперь в центре внимания - единый стиль внедрения зависимостей. - Поддержка Java Records. - Удалены устаревшие конструкции вроде SecurityManager. Обновлённый TCK Тестовая инфраструктура переписана на JUnit 5 и Maven, вместо старого Ant. Это упрощает сертификацию, ускоряет тестирование и снижает барьер входа для новых участников. Поддержка Java 17 и 21, включая Virtual Threads — да, Jakarta EE те

Как не облажаться с типами данных в 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:

📊 Java в 2025 году: взгляд на результаты опроса Stack Overflow Эксперт Spring АйО Рустам Курамшин разобрал свежий отчёт Stack Overflow за 2025 год о результатах ежегодного опроса разработчиков за 2025 год, и это отличный повод взглянуть на экосистему Java через призму статистики и интересов сообщества. Что происходит с Java и где мы сегодня? 🥈 Java — в топе, но не в лидерах Java остаётся устойчиво популярной, но теряет позиции в рейтинге языков, которыми реально пользуются. В 2025 году она набрала 29.4% среди всех респондентов — это седьмое место. Для сравнения: 🛑JavaScript — 66% 🛑Python — 57.9% 🛑TypeScript — 43.6% Что интересно: C# проигрывает Java (27.8%), хотя отрыв минимальный. Kotlin находится далеко внизу с 10.8%. 👩‍💻 А как насчёт любви к Java? В рейтинге «admired & desired» Java получила: 🛑15.8% хотят продолжать работать с ней 🛑41.8% тех, кто с ней работал, хотят продолжать Это не худшие цифры, но явно не звёздные. Rust, например, вызывает желание продолжать у 72.4% разработчиков. 👩‍💻 Что по инструментам разработки? Java-разработчики традиционно предпочитают инструменты JetBrains, и это подтверждается: 🛑IntelliJ IDEA — на 4 месте по популярности (27.1%) и на втором по желанию использовать (17.5%) 🛑VS Code по-прежнему вне конкуренции (используется 75.9%, желают 48.9%), но для серьёзной Java-разработки — не первый выбор 🛑Gradle и Maven уверенно держатся в середине таблицы среди сборщиков и DevOps-инструментов, уступая npm, Docker и Terraform. 👩‍💻 Java на бэкенде Среди web-фреймворков Spring Boot — единственный представитель Java в топе, с 14.7% популярности. Это чуть меньше, чем у FastAPI (14.8%), и сильно меньше Node.js (48.7%) и React (44.7%). Однако в категории "admired" Spring Boot выглядит лучше — 53.7% разработчиков, использовавших его, хотят продолжать. Это говорит о стабильности интереса к Spring Framework. 👩‍💻 Базы данных: знакомые лица Всё, что любят Java-разработчики, — на месте: 🛑PostgreSQL — №1 по популярности и симпатиям 🛑MyS

🍃 Эксперт Spring АйО Рустам Курамшин на HighLoad: Двоичная Java: CDS, CRaC и AOT для ускорения запуска и прогрева JVM Совсем недавно эксперт сообщества Spring АйО Рустам Курмашин выступил на немалоизвестной конференции HighLoad с докладом, в котором удалось поговорить о новшествах, которые появились в Java и JVM: CRaC и GraalVM. Они призваны решать упомянутые проблемы. Но разработчики и рынок еще к ним не готовы, потому что не знают, как именно это работает и что, вообще, с этим делать. 😉Смотреть тут: https://www.youtube.com/watch?v=S1g4-uHJ0QM

👩‍💻➕🤘 🟰 🥇 Spring AI, ChatGPT и Java: как мы делали ИИ-агента на хакатоне МТС Статья на Хабр - https://habr.com/ru/companies/ru_mts/articles/948448/ Два года назад я плотно погрузился в хакатоны. Это особая среда, где команды разработчиков, ML/AI-инженеров, Data-аналитиков за короткое время превращают идеи в работающие прототипы. Почти всегда это даёт мощный толчок кругозору в разработке. Не так давно мы с моей командой Java Boys участвовали в MTC True Tech Hack 2025 — крупном AI-хакатоне, где нужно было разработать решения на базе LLM и инструментов МТС The Platform. Наш проект — Vibe JSON — мы делали на Java, Spring Boot, Spring AI и Jmix. Основная идея — генерировать JSON-схемы для low-code платформы через диалог с LLM. Мы интегрировали OpenAI API через Spring AI, использовали structured output, function calling - всё в лучших традициях разработки AI-агентов. Spring AI показал себя мощным инструментом: можно строить настоящих ИИ-агентов, а не просто AI чат-ботов. На Хабре, в блоге МТС, вышла моя подробная статья о хакатоне и технических деталях проекта: https://habr.com/ru/companies/ru_mts/articles/948448/ Исходный код проекта на GitHub: https://github.com/Java-Boys-Hackathon-Team/vibe-json В статье: - немного о хакатонной культуре в России; - как эффективно работать командой и не сгореть за 48 часов; - как Java-разработчику использовать Spring AI для построения ИИ-агентов. Если вы интересуетесь интеграцией LLM в свои java/kotlin-проекты на Spring — буду рад комментариям.

Java-митап от Jmix в Питере 👨‍💻 Иногда скорость разработки — решающий фактор. Например, когда у вас команда backend-разработчиков и нужно быстро собрать fullstack-приложение. Или когда хочется, чтобы UI создавался из данных — таблицы, списки, формы появлялись без лишней возни с фронтендом. С Jmix такие задачи решаются быстро. Этот фреймворк реально ускоряет разработку — особенно когда сроки поджимают. Я давно использую Jmix — в том числе на хакатонах, где важна каждая минута. И каждый раз поражаюсь, насколько продуманный инструмент создала команда, которую я горжусь знать лично. Мои друзья из Jmix 13 ноября проводят митап в Питере! Участие бесплатное, но количество мест ограничено. Если вы живёте в этом вечно дождливом городе в культурной столице — приходите. Вас ждёт глубокое погружение в мир быстрой разработки web-приложений на Java и живое общение с теми, кто делает Jmix. Подробности тут 👉 https://t.me/jmixplatform/550

Почему нужно посмотреть АльфаГо 🎬 В 2016 году, задолго до резкого скачка популярности ИИ и нейросетей, компьютерная программа AlphaGo победила в го одного из сильнейших профессиональных игроков мирового уровня - Ли Седоля. Го - это настольная стратегическая игра, которая появилась в Китае несколько тысяч лет назад. В го простые правила: на доске нужно ставить белые и чёрные камни на пересечении линий, стремясь захватить как можно большую территорию. При всей своей простоте количество возможных партий в го превышает число атомов во Вселенной. В Корее и Китае игра в го считается одним из видов искусства наравне с живописью и музыкой. В 1997 году шахматный суперкомпьютер Deep Blue от IBM, похожий на огромный шкаф, прибил обыграл Гарри Каспарова. Шахматы в определённом смысле подходят для моделирования классическими алгоритмами, за которыми стоит понятная математика (поиск ходов по дереву и оценка). С го всё совсем не так. В го больше свободы и творчества. Партия в го имеет много степеней свободы (порядка 200 возможных ходов на каждом ходе). Даже если мы объединим все компьютеры в мире, то не сможем просчитать все возможные ходы в текущей игре. Это сильно усложняет моделирование го с помощью алгоритмов. В 2010 году Демис Хассабис основал DeepMind, впоследствии компанию приобрёл Google. В DeepMind придумали новый подход к построению систем искусственного интеллекта: модель изначально ничего не знает о данных, с которыми работает, она с ними «играет». В играх есть соревновательный элемент - счёт. Модель ничего не знает о правилах игры, она может что-то делать с данными и знает, какой счёт. Так она самообучается. Этот необычный подход позволил DeepMind сначала обучить ИИ играть в игры Atari, затем превзойти всех мировых чемпионов в го и шахматах и решить серьёзную научную проблему в биологии - научиться предсказывать структуру белка. Последнее достижение в 2024 году было удостоено Нобелевской премии по химии (Хассабис получил треть премии). Сейчас мы - свидетели взр

👩‍💻👩‍💻 Разработка ИИ-агентов на Spring AI и Jmix 🎞 Смотреть выпуск: https://www.youtube.com/watch?v=1cYw1pfT1u0 😀 Исходный код проекта на GitHub: https://github.com/Java-Boys-Hackathon-Team/jmix-ai-chat Последние пару лет Java-разработчики оказались в интересной ситуации. С одной стороны, вокруг LLM и AI огромный хайп. С другой - большая часть материалов сводится к демонстрации пары запросов в ChatGPT и рассказам про «революцию, которая всё изменит». Но когда начинаешь делать реальные проекты, быстро выясняется, что основная работа находится совсем в другом месте. Как хранить историю диалогов? Как организовать потоковую генерацию ответов? Как подключать разные модели? Как строить пользовательский интерфейс? Как превратить набор запросов к LLM в полноценное приложение? Именно поэтому мы вместе с Дмитрием Черкасовым из Jmix и моим другом java-разработчиком Рустамом Гулямовым решили записать серию практических видео про Spring AI. В первом выпуске собираем AI-чат на Spring AI и Jmix и по пути разбираем: • подключение Spring AI к проекту; • работу с OpenAI API; • память диалогов для ИИ-агента; • потоковую выдачу ответов; • создание UI-интерфейса; • архитектурную основу для дальнейшего развития AI-приложений. Получился полноценный рабочий проект, который можно взять за основу для собственных экспериментов. В следующих частях планируем поговорить про tool calling, structured output, RAG, векторные базы данных, интеграцию внешних сервисов и построение более сложных агентных сценариев на Java.

2023 — попробуйте ChatGPT. 2024 — попробуйте генерировать код. 2025 — попробуйте ИИ-агентов. 2️⃣0️⃣2️⃣6️⃣ — пора разобраться, как встроить ИИ в управляемый процесс разработки.   Сегодня вопрос уже не в том, использовать ли ИИ в разработке. Вопрос в другом: как с его помощью создавать реальные бизнес-системы и не превращать инженерный проект в творческое изделие?   В апреле мы провели вебинар «Вайб-кодинг в энтерпрайз: 5 блокеров и путь к управляемой разработке». Можно пересмотреть — VK Video / YouTube. Теперь переходим от концепции к практике. ⬇️   📆 16 июня в 16:00 по МСК 🛠 проведем бесплатный воркшоп: «Создаем B2B CRM с ИИ на Java».   На примере open-source CRM покажем, как пройти путь от спецификации до первого рабочего контура корпоративного приложения.   Разберем: ⏩ как поставить задачу ИИ-агенту и удерживать его в рамках проекта; ⏩как создавать модель данных, экраны и бизнес-логику; ⏩как использовать документацию, скиллы и проверки IDE; ⏩какие ошибки типичны для агентного режима; ⏩чем управляемая ИИ-разработка отличается от вайб-кодинга.   Воркшоп проведут: ▶️ Виктор Фадеев, руководитель продукта Джеймикс; ▶️ Дмитрий Ващенко, ведущий тренер Джеймикс; ▶️ Дмитрий Змитрович, CEO Kodacode.   Если вам интересен не очередной разговор про ИИ, а практический сценарий разработки корпоративного Java-приложения — ждем вас!   📌 Регистрируйтесь.

Reflection в Java: временно выходим из правил языка Reflection часто описывают как API, через который можно узнать поля класса, найти метод по имени или вызвать private-конструктор. Такое описание верное, но почти ничего не объясняет. Главная идея reflection связана с устройством JVM. После компиляции Java-код превращается в class-файлы с метаданными о типах, методах, полях, модификаторах и связях между классами. Во время загрузки классов JVM собирает из этих данных модель выполняемой программы. Без нее JVM не смогла бы определить, какую реализацию size() вызвать здесь: List values = getValues(); values.size(); Тип объекта и иерархия его класса известны JVM во время выполнения. Reflection дает Java-коду доступ к части этих метаданных. Например, мы можем загрузить класс, найти конструктор и вызвать метод, хотя конкретный тип не был известен во время компиляции: Class type = Class.forName(className); Constructor constructor = type.getConstructor(); Object instance = constructor.newInstance(); Method method = type.getMethod(“process”, String.class); Object result = method.invoke(instance, “data”); На этой возможности построены dependency injection, ORM, сериализация, тестовые библиотеки и многие другие механизмы Java-экосистемы. Но у такой гибкости есть цена. При обычном вызове компилятор заранее проверяет тип объекта, сигнатуру метода, аргументы и доступность. В рефлексивном коде значительная часть этих проверок переносится в runtime. Из-за этого появляются знакомые особенности Core Reflection API: - метод ищется по имени и массиву типов аргументов - параметры передаются как Object[] - примитивы требуют boxing и unboxing - результат Method.invoke() возвращается как Object - ошибка внутри вызываемого метода оборачивается в InvocationTargetException - проблемы с сигнатурой или доступом обнаруживаются во время выполнения - setAccessible(true) позволяет обойти часть правил инкапсуляции Можно сказать, что рефлексивный код написан на Java, но работает по пра

73 минуты истории Java: от Oak до virtual threads Все уже наверное слышали. На канале CultRepo вышел документальный фильм The Java Story. И это, пожалуй, самая полная экранизация истории Java из тех, что у нас теперь есть. История начинается задолго до enterprise-разработки, Spring и обсуждений Hibernate. Java - тогда ещё Oak - создавалась внутри проекта Green для бытовых вычислительных устройств и интерактивного телевидения. Проект проиграл ключевой тендер, команду практически распустили, а сама технология оказалась никому не нужна. Затем появился браузер Mosaic - и инженеры Sun поняли, что Oak можно использовать для запуска интерактивных приложений прямо на веб-страницах. Так начался один из самых удачных пивотов в индустрии. Дальше фильм проходит почти по всей биографии платформы: - интеграция с Netscape и внезапный взлёт Java в 1995 году - попытка Microsoft создать несовместимую версию Java для Windows; - рождение Spring и Hibernate как реакции на эту сложность - открытие исходников Java и создание OpenJDK - Java 8, которая фактически стала последним шансом вернуть языку развитие - переход на шестимесячный цикл релизов - Loom, virtual threads, Valhalla, Panama и дальнейшая эволюция JVM Интернсен фрагмент о появлении Spring и Hibernate. Сегодня они воспринимаются как естественная часть Java-экосистемы, но из фильма хорошо видно, что оба проекта выросли из несогласия с официальным направлением развития энтерпрайзной Java. Open source-сообщество предложило более практичные решения - а затем уже сама платформа начала заимствовать найденные ими идеи. Историю рассказывают люди, которые непосредственно её создавали: Джеймс Гослинг, Джошуа Блох, Брайан Гётц, Марк Рейнхольд, Род Джонсон, Гэвин Кинг, создатель Tomcat Джеймс Дункан Дэвидсон, создатель Kotlin Андрей Бреслав и многие другие. Получилась история того, как Java несколько раз оказывалась на грани провала, меняла направление и при этом умудрялась сохранять совместимость с огромной экосистемой. Если вы за

Фильтр Блума: множество, которое иногда ошибается Представим сервис с миллионами идентификаторов. Нам нужно быстро отвечать на вопрос: встречался ли такой ID раньше? Хранить все значения в условном HashSet может быть слишком дорого. Если точный положительный ответ не обязателен, можно использовать фильтр Блума. Он возвращает один из двух результатов: точно отсутствует и возможно присутствует. Ложноположительный ответ возможен. Ложноотрицательный - нет. Если фильтр говорит, что элемента не было, значит его действительно не добавляли. Как он устроен Внутри находится массив битов и несколько хеш-функций. При добавлении элемента вычисляется несколько позиций: "java" -> [2, 7, 12] 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 ↑ ↑ ↑ Биты в этих позициях устанавливаются в 1. При проверке элемента фильтр снова вычисляет те же позиции. Если хотя бы один бит равен нулю, элемента точно нет. boolean mightContain(String value) { for (int index : indexes(value)) { if (!bits.get(index)) { return false; } } return true; } Если все биты установлены, элемент, вероятно, добавляли. Те же позиции могли независимо занять другие значения, поэтому гарантировать наличие нельзя. Как выглядела бы реализация на Java Для хранения битов подойдет BitSet. Методу add() нужно вычислить несколько индексов и установить соответствующие биты. Метод mightContain() вычисляет те же индексы и проверяет, что каждый бит установлен. Запускать отдельную хеш-функцию для каждого индекса необязательно. Обычно используют double hashing: вычисляют два хеша, а остальные получают из их комбинаций. При создании фильтра задаются два параметра: BloomFilter filter = new BloomFilter(1_000_000, 0.01); Первый параметр - ожидаемое число элементов. Второй - допустимая вероятность ложного срабатывания. Для миллиона элементов и вероятности ошибки 1% потребуется около 9,6 миллиона бит, то есть примерно 1,14 МБ. Оптимальное количество хешей в этом случае равно семи

⚙️ В HTTP появился метод QUERY. Пора прощаться с POST /search? У бэкенд-разработчиков много лет был довольно неловкий выбор. Пока фильтров мало, используем GET: GET /orders?page=2&status=PAID&sort=createdAt,desc Потом поиск усложняется. Появляются диапазоны дат, группы условий, вложенные фильтры. Query string постепенно превращается в плохо читаемый DSL. Заодно приходится учитывать ограничения на длину URI и то, что адрес запроса может попасть в логи. Обычно в этот момент появляется такой эндпойнт: POST /orders/search Content-Type: application/json { "status": ["PAID", "SHIPPED"], "createdAt": { "from": "2026-06-01", "to": "2026-06-30" }, "customer": { "country": "NL" } } Решение рабочее. POST вообще не ограничен созданием ресурсов. Сервер может обрабатывать его тело по собственной семантике. Проблема в другом: на уровне HTTP POST считается потенциально небезопасным и не идмептентным. Прокси, клиенты и другая инфраструктура не знают, что наш /search только читает данные. Такой запрос нельзя автоматически повторять или полноценно кэшировать без дополнительных договоренностей. Передать тело в GET технически возможно. Но RFC 9110 говорит, что у содержимого GET-запроса нет общепринятой семантики. Некоторые серверы и промежуточные узлы могут отклонить такой запрос. Среди причин упоминаются даже атаки класса request smuggling. В июне 2026 года IETF опубликовала RFC 10008 с новым методом QUERY: QUERY /orders HTTP/1.1 Content-Type: application/json Accept: application/json { "status": ["PAID", "SHIPPED"], "total": { "min": 100, "max": 1000 } } QUERY предназначен для запросов, описание которых передается в теле. Формат может быть любым, если он обозначен через Content-Type: JSON, SQL, JSONPath или собственный язык фильтрации. Спецификация закрепляет за QUERY три свойства: - safe - клиент не запрашивает изменение состояния целевого ресурса - idempotent - запрос можно безопасно повторить - cacheable - ответ разрешено кэширова

Anthropic опубликовали AI-Native SDLC плейбук Его основная мысль: агенты уже способны генерировать код намного быстрее человека, но окружающие процессы почти не изменились. Планирование, согласования, тестирование, проверка безопасности и выпуск по-прежнему работают с человеческой скоростью. Узкое место просто переместилось из написания кода в соседние этапы. Anthropic называет предлагаемую модель AI-native SDLC. Привычный линейный процесс превращается в замкнутый цикл, внутри которого каждый этап создает версионируемый артефакт для следующего: intent.md -> spec.md -> plan.md -> код и тесты -> PR с результатами проверок -> отчет об инциденте или новый intent.md Все это хранится в Git. История коммитов одновременно становится журналом изменений: кто сформулировал задачу, что предложил агент, какие решения принял человек и что в итоге попало в продакшен. Как выглядит сам процесс? На этапе планирования автор идеи обсуждает проблему с Claude. Результат фиксируется в intent.md: что требуется изменить, зачем, какие системы затрагиваются и какие ограничения нужно учитывать. Владелец продукта проверяет документ и принимает решение о продолжении работы. Дальше агент превращает намерение в spec.md с требованиями и проектным решением. Политики безопасности, архитектурные правила и требования к интерфейсу подключаются через Skills. Спорные места агент должен явно отметить, а человек - разрешить до начала реализации. Разработка начинается с plan.md. В нем перечисляются изменяемые файлы, порядок работы, риски и проверки результата. После утверждения плана агент пишет код. Контекст проекта хранится в CLAUDE.md, повторяемые правила оформляются как Skills, а обязательные ограничения обеспечиваются через hooks. Для тестирования предлагается два уровня. Первый - обычные сборка, линтеры и автоматические тесты, которые агент обязан запустить перед завершением задачи. Второй - evals для проверки самого агента. Если команда меняет модель, системные инструкции, Skills или hooks,

JEP 544: JVM будет сохранять машинный код между запусками JEP 544 (Ahead-of-Time Code Compilation) предложен в JDK 28, релиз в марте 2027. Это очередной слой AOT-кэша из Project Leyden. В JDK 24 туда попали загруженные и слинкованные классы (JEP 483), в JDK 25 - профили методов (JEP 515). Теперь дошла очередь до самого машинного кода. Как это работает На обучающем запуске JVM компилирует горячие методы обычными C1 и C2 и складывает результат в кэш. В рабочем запуске запрос на компиляцию метода закрывается готовым кодом. Процедура та же, что и раньше: -XX:AOTCacheOutput при обучении, -XX:AOTCache в проде. Включать ничего не нужно. Код из кэша остаётся обычным кодом HotSpot. Если рабочая нагрузка ушла в сторону от обучающей, метод деоптимизируется и перекомпилируется JIT-ом, как любой другой. Профили из JEP 515 при этом продолжают работать: по ним JVM выбирает порядок загрузки кода и пересобирает методы. Чем AOT-код хуже JIT-кода JIT компилирует метод, когда нужные классы давно инициализированы. Он подставляет значения static final полей как константы и выбрасывает проверки инициализации. Код из кэша начинает работать раньше, чем классы успели инициализироваться, а значение static final может отличаться от запуска к запуску. Поле приходится читать по-настоящему. Для методов, которые обращаются к статике других классов, C2 собирает две версии: медленную с проверками инициализации и быструю без них. Поэтому JIT никуда не уходит. AOT-код даёт быстрый старт, до пика доводит перекомпиляция. Когда кэш не сработает Обучающий и рабочий запуски должны совпадать по архитектуре процессора, набору инструкций и сборщику мусора: барьеры GC вшиты в машинный код. Собрали образ на хотсе с AVX-512, pod уехал на узел без него - код из кэша не загрузится. Ошибки не будет, JVM молча перейдёт на интерпретатор и JIT. В кластере с разнородными узлами это легко пропустить. Поддерживаются x64 и AArch64, из сборщиков - Serial, Parallel, G1 и ZGC. Цифры По данным JEP, AOT-кэш без ко