Project Valhalla, один из самых затяжных проектов в истории Java, наконец добрался до первой официальной preview-версии: JEP 401 планируют влить в основную ветку OpenJDK уже в начале июля с прицелом на JDK 28. Для Java-разработчиков это не просто еще один JEP, а попытка починить старую конструктивную проблему языка: почти все в Java до сих пор живет как ссылочный объект, даже когда по смыслу это просто значение.
О планах интеграции сообщает The Register со ссылкой на инженера Oracle Лоис Фолтан. По ее словам, изменение настолько крупное, что другим коммиттерам OpenJDK рекомендовали временно избегать больших коммитов, чтобы не осложнять слияние. Масштаб действительно не рядовой: pull request для первого preview JEP 401 добавляет более 197 тысяч строк кода и затрагивает 1816 файлов. Для OpenJDK это тот случай, когда слово «большой» не выглядит редакторским преувеличением.
Формально речь идет о JEP 401, который описывает Value Classes and Objects, часть Project Valhalla. До сих пор preview этой функциональности был доступен только в early-access сборках. Теперь технология движется в mainline, то есть выходит из состояния «посмотреть можно, но руками лучше не трогать» в режим, где экосистема начнет готовиться к реальной адаптации. Сейчас актуальной версией JDK остается JDK 26, JDK 27 ожидается в сентябре 2026 года, а JDK 28 должен выйти в марте 2027-го. Следующая LTS-версия, если ориентироваться на текущий ритм релизов, вероятнее всего будет JDK 29 в сентябре 2027 года.
Зачем все это понадобилось после стольких лет разработки? Проблема старая и для Java довольно болезненная. В языке есть примитивы вроде int, char, byte и double, но почти все остальное существует как ссылочный тип с идентичностью объекта. Это означает, что два объекта с одинаковыми данными могут быть логически равны, но физически это все равно две разные сущности в памяти. Классический пример — LocalDate. Две даты с одинаковыми значениями дня, месяца и года не будут равны через оператор ==, потому что == сравнивает ссылки, а не содержимое. Приходится использовать equals(), что давно стало привычкой, но не сделало модель проще.
Еще показательнее история с Integer. Это обертка над int, и в ней давно живет особенность, из-за которой небольшие значения до 128 кэшируются. В результате два Integer с маленьким числом иногда оказываются равны через ==, а с более крупным — уже нет, хотя с точки зрения бизнеса, API и здравого смысла число то же самое. Поэтому IDE и статические анализаторы годами предупреждают: сравнивать Integer через == не надо. JEP 401 пытается убрать именно этот класс «магии», который новички принимают за баг, а опытные разработчики — за очередной ритуал Java, о котором лучше просто помнить и не задавать лишних вопросов.
Смысл value-классов в том, что экземпляры таких классов не имеют собственной объектной идентичности и определяются только значениями своих полей. Для платформы это открывает дорогу к другой модели хранения и оптимизации. JVM сможет размещать такие объекты так, как выгоднее по производительности и памяти, без обязательной нагрузки ссылочной семантики. В материале отдельно подчеркивается, что ссылочные типы занимают больше памяти и требуют разыменования, чтобы добраться до данных. Для структур, которые часто итерируются или массово создаются, это не академическая тонкость, а прямой разговор о latency, кэш-локальности и накладных расходах GC.
На практике это означает два важных сценария. Первый — часть классов JDK, включая Integer, со временем переведут в value-классы. Второй — разработчики смогут создавать собственные value-классы. Но у этой гибкости есть цена: Project Valhalla не маскируется под полностью обратносуместимое косметическое обновление. Архитектор Java Брайан Гетц прямо говорит, что некоторые изменения будут намеренно ломающими. Самый наглядный пример: код, который синхронизируется на объектах Integer, начнет падать с исключением. И это вполне логично: если объект больше не играет роль стабильной сущности с идентичностью, использовать его как монитор для синхронизации уже нельзя.
При этом Гетц отдельно охлаждает ожидания тех, кто уже мысленно записал Valhalla в обязательный набор ближайшей LTS-версии. По его оценке, надеяться на выход JEP 401 из preview уже в JDK 29 слишком оптимистично. Иначе говоря, даже если preview приедет в JDK 28, в следующей LTS эта функциональность с высокой вероятностью все еще останется предварительной. Для бизнеса и платформенных команд это важная оговорка. Пощупать новую модель можно будет раньше, чем внедрять ее в консервативные production-контуры. Для компаний, которые живут на LTS-циклах и не любят экспериментировать с семантикой языка в бою, это скорее хорошая новость: будет время посмотреть на совместимость библиотек, поведение фреймворков и реакцию экосистемы.
Есть и более дальняя перспектива. Гетц напоминает, что JEP 401 — это только первый слой Project Valhalla. Полноценная value-semantics для объектов упирается не только в отказ от идентичности, но и в более сложные вопросы вроде nullability и безопасного поведения при гонках. То есть Java пока не приходит в точку, где «объект как значение» работает всегда и везде без оговорок. Скорее платформа снимает первый крупный барьер, после которого можно будет перестраивать и VM-примитивы, и соседние API. В том числе от этого зависит дальнейшая судьба Vector API, который, по словам Гетца, сможет выбраться из инкубации после перехода на базовые механизмы VM, появляющиеся благодаря Valhalla.
Главный вывод для русскоязычной Java-аудитории довольно приземленный. Project Valhalla перестает быть вечным обещанием с конференционных слайдов и входит в фазу, где его уже придется учитывать в дорожных картах, дизайне библиотек и внутреннем обучении команд. Но это не тот случай, когда стоит срочно переписывать доменные модели под новую семантику. Ближайшие полтора года, скорее всего, уйдут на то, чтобы Java-сообщество проверило, насколько дорого ей обойдется отказ от привычки считать любой объект «настоящим объектом». Детали первоисточника и цитаты Брайана Гетца можно посмотреть в материале .