JEP 296: Consolidate the JDK Forest into a Single Repository

Аннотация

Объединить многочисленные репозитории леса JDK в один репозиторий, чтобы упростить и оптимизировать разработку.

Что не является целью

Добавление исходного кода FX в лес JDK не входит в это предложение.

Мотивация

Уже много лет полная кодовая база JDK разбита на многочисленные репозитории Mercurial. В JDK 9 восемь репозиториев: root, corba, hotspot, jaxp, jaxws, jdk, langtools и nashorn.

Хотя модель с несколькими репозиториями даёт некоторые преимущества, у неё много недостатков, и она плохо поддерживает ряд полезных операций управления исходным кодом. В частности, невозможно атомарно зафиксировать взаимозависимые наборы изменений в нескольких репозиториях. Например, если сегодня код одного исправления ошибки или RFE затрагивает и репозиторий jdk, и репозиторий hotspot, изменение обоих репозиториев нельзя выполнить атомарно в лесу, где размещены эти два отдельных репозитория. Изменения, затрагивающие несколько репозиториев, встречаются часто: более 1100 идентификаторов ошибок использовались повторно в разных репозиториях леса JDK. Эти 1100+ ошибок, затрагивающих несколько репозиториев, — лишь нижняя граница числа ошибок, логически затрагивающих несколько репозиториев, поскольку некоторые инженеры используют отдельные идентификаторы ошибок для публикации изменений в разные репозитории.

Это несоответствие между разделением на репозитории Mercurial и единством инженерной работы сводит на нет одно из главных преимуществ современных систем управления исходным кодом: отслеживание изменений в наборах файлов, а не только в отдельных файлах. Как следствие, это несоответствие между транзакциями SCM и логическими транзакциями усложняет использование таких инструментов, как Mercurial bisect.

У отдельных репозиториев нет цикла разработки, отдельного от JDK в целом: все репозитории продвигаются синхронно с циклом продвижения сборок JDK. Множество репозиториев создаёт для новых разработчиков более высокий, чем необходимо, порог входа и привело к обходным решениям, таким как скрипт «get source».

Описание

Чтобы решить эти проблемы, был разработан прототип объединённого леса. Прототип доступен по адресу:

http://hg.openjdk.java.net/jdk10/consol-proto/

Некоторые из вспомогательных скриптов преобразования, использованных для создания прототипа, приложены в виде unify.zip.

В прототипе. восемь репозиториев объединены в один репозиторий с помощью автоматического скрипта преобразования, который сохраняет историю на уровне отдельных файлов, при этом объединённый лес синхронизирован по тегам, которыми отмечаются продвижения сборок JDK. Комментарии к наборам изменений и даты их создания также сохранены.

В прототипе есть ещё один уровень реорганизации кода. В объединённых лесах код модулей Java, как правило, собран в одном каталоге src верхнего уровня. Например, сейчас в лесу JDK есть каталоги, организованные по модулям, вида

$ROOT/jdk/src/java.base
...
$ROOT/langtools/src/java.compiler
...

В объединённом лесу этот код организован иначе:

$ROOT/src/java.base
$ROOT/src/java.compiler
...

В результате относительный путь исходного файла в модуле от корня репозитория после объединения и слияния каталогов src сохраняется.

Аналогичная, но менее радикальная реорганизация выполнена для каталогов тестов: из

$ROOT/jdk/test/Foo.java
$ROOT/langtools/test/Bar.java

в

$ROOT/test/jdk/Foo.java
$ROOT/test/langtools/Bar.java

Поскольку сейчас работа находится в стадии прототипа, не все её части полностью завершены, и в некоторых областях доводку можно улучшить. Исходный код HotSpot на C/C++ перенесён в общий каталог src рядом с модуляризованным кодом Java.

Хотя регрессионные тесты запускаются на текущем состоянии прототипа, возможно дальнейшее объединение конфигурационных файлов jtreg, и оно может быть выполнено в будущем.

Альтернативы

Одна из альтернатив — просто оставить текущий набор репозиториев. При переходе к одному репозиторию можно было отбросить историю некоторых или всех репозиториев, но этот вариант был отклонён. Рассматривалось объединение основного подмножества репозиториев, но от него отказались в пользу простоты единого репозитория.

Тестирование

Для проверки содержимого файлов для каждого тега продвижения сборки использовался скрипт, проверявший, что содержимое разделённого леса на этом теге совпадает с содержимым объединённого репозитория на том же теге. Для одного из недавних тегов JDK 9 сравнивались сборки разделённого и объединённого лесов на одном и том же теге: различия были лишь незначительными и объяснимыми.

Риски и допущения

Описанное выше тестирование должно снизить наиболее серьёзные риски повреждения файлов и ошибочных сборок. Хотя основные части работы, необходимой для объединения, в прототипе завершены, различные более мелкие вспомогательные функции могут быть не закончены к моменту, когда объединение будет введено в эксплуатацию. Кодовые базы до и после объединения не связаны между собой с точки зрения Mercurial. Для прямого и обратного портирования придётся использовать diff-файлы (с соответствующим образом исправленными путями) вместо экспорта и импорта наборов изменений.