Oracle фактически показала Java-сообществу две взаимоисключающие модели работы с ИИ: OpenJDK в апреле 2026 года запретил вклад, созданный с помощью генеративного ИИ, а GraalVM почти одновременно разрешил такие материалы при соблюдении правил ответственности автора. Для разработчиков, тимлидов и компаний, которые живут в Java-стеке и уже привыкли к AI-ассистентам в IDE, это не академический спор, а вопрос о том, где граница между ускорением разработки и юридическим риском.
О расхождении между двумя Oracle-проектами сообщает InfoQ. Ситуация примечательна не только контрастом формулировок, но и тем, что оба проекта опираются на один и тот же Oracle Contributor Agreement, то есть соглашение, по которому автор передает Oracle права на свой вклад без ограничений. Иначе говоря, база у них общая, а выводы противоположные.
Позиция OpenJDK выглядит максимально жесткой. В начале апреля 2026 года управляющий совет проекта утвердил временную политику, которая запрещает добавлять контент, сгенерированный большими языковыми моделями, диффузионными моделями и похожими системами глубокого обучения. Под запрет попали не только исходники, но и текст, изображения, pull request'ы в GitHub, письма в рассылках, страницы wiki и задачи в JBS. Формулировка широкая и оставляет мало пространства для трактовок: если вклад создан полностью или даже частично машиной, в репозиторий ему нельзя.
Аргументов у OpenJDK три. Первый касается нагрузки на ревьюеров: правдоподобный, но неверный или плохо поддерживаемый код съедает время людей, которых и без того мало. Второй связан с надежностью и безопасностью: JDK лежит в основе критически важных систем, а значит порог доверия к изменениям должен быть выше обычного. Третий аргумент юридический. Поскольку OCA требует, чтобы автор действительно владел правами на передаваемый код, OpenJDK не хочет связываться с серой зоной вокруг авторства AI-генерации, которая, как сказано в политике, остается предметом активных судебных споров.
При этом OpenJDK не объявляет войну любому использованию ИИ как классу инструментов. Генеративный ИИ разрешено применять приватно: чтобы понимать кодовую базу, отлаживать ее, проводить ревью или исследовать варианты решения. Нельзя только приносить в проект результат такой генерации. В FAQ это правило специально заземлили на бытовом примере: если разработчик взял 100 строк, сгенерированных моделью, и вручную поправил 10 из них, вклад все равно считается частично AI-созданным и потому запрещен. Допустимыми остаются более традиционные функции редакторов и IDE вроде проверки орфографии, грамматики, автодополнения и рефакторинга, если они не опираются на LLM или похожие deep learning-системы. В ближайшее время участникам OpenJDK придется подтверждать соблюдение этой политики отдельным чекбоксом в Skara, автоматизированной системе проверки pull request'ов.
На другом полюсе находится GraalVM, проект Oracle Labs, который не подчиняется управляющему совету OpenJDK. В середине апреля 2026 года команда GraalVM уточнила собственную политику AI-assisted contributions и прямо разрешила использовать coding assistants при подготовке изменений. Под действие правил попали код, тесты, документация, текст коммитов, pull request'ы и issues. Более того, 3 июня 2026 года проект выпустил отдельный guide по терминологии и стилю документации для AI coding assistants, то есть здесь генеративный ИИ рассматривают уже не как неудобную аномалию, а как рабочий инструмент, который нужно дисциплинировать.
Ключевой принцип GraalVM не в запрете, а в переносе полной ответственности на человека. Автор обязан понимать весь внесенный код, проверить его корректность, уметь объяснить архитектурные решения и отвечать на вопросы ревьюеров без сакральной фразы «так подсказала модель». Если участник не может защитить или поддерживать AI-assisted change, такой вклад может быть отклонен. Для мейнтейнеров тоже не сделано ни одной скидки: наличие ИИ в процессе не означает, что изменение автоматически качественное, готовое к ревью или заслуживает особого доверия. При необходимости ревьюеры вправе спрашивать о происхождении кода, лицензировании, замысле, тестировании и уровне понимания автора.
Интересно, что GraalVM не выдумывала правила с нуля. В политике прямо сказано, что она ориентировалась на подход Linux kernel к AI CodingAssistants, но смягчила его. Например, в Linux contributions рекомендуется помечать тегом Assisted-by, а в GraalVM явное указание конкретной модели или инструмента оставили необязательным. Раскрытие использования ИИ там скорее поощряется, если это помогает ревьюеру понять происхождение изменений, но не превращается в обязательный ритуал отчетности.
Для рынка разработки тут важен не спор о вкусе формулировок, а более неприятный вывод: даже внутри орбиты одного вендора не существует общего ответа на вопрос, что делать с генеративным ИИ в open source. Один Oracle-проект считает юридическую неопределенность достаточным основанием для запрета, другой полагает, что достаточно личной ответственности контрибьютора и обычного инженерного контроля. Для команд, которые одновременно работают с OpenJDK, GraalVM и другими инфраструктурными проектами, это означает рост операционной сложности. Политика использования AI-ассистентов теперь должна жить не на уровне абстрактного «мы разрешаем Copilot», а на уровне конкретных репозиториев, лицензий, CLA-соглашений и требований к provenance.
Для русскоязычной IT-аудитории здесь есть еще один практический урок. Многие компании уже встроили AI-инструменты в повседневную разработку и считают это вопросом производительности, а не комплаенса. История OpenJDK показывает, что для фундаментальных платформ этого недостаточно: скорость генерации кода не отменяет нагрузку на ревью, риски поддержки и вопросы владения правами. История GraalVM, наоборот, показывает, что полный запрет тоже не единственный путь, если у проекта есть зрелые процессы code review и культура персональной ответственности. Проблема в том, что между этими двумя режимами нельзя переключаться одним тумблером на уровне IDE.
Теперь главный вопрос не в том, можно ли использовать генеративный ИИ вообще, а в том, кто первым навяжет отрасли рабочий стандарт проверки происхождения кода и ответственности за него. Oracle уже заявила, что готовит полноценную политику AI-вкладов для OpenJDK. Если она останется столь же жесткой, Java-экосистема получит один из самых консервативных прецедентов среди крупных open-source проектов. Если правила смягчат, значит даже в проектах с критической инфраструктурной ролью победит не запрет, а модель «использовать можно, но отвечать придется по-взрослому».