Java goes Git: Proposal to migrate OpenJDK
Project Skara’s goal in July last year was to look into the viable SCM alternatives to Mercurial. It looks like Git is to be OpenJDK’s new home, at least following JEP 357’s proposal. Let’s take a closer at look at what’s going on.
A new JDK Enhancement Proposal, or JEP, has been put forward proposing the migration of the OpenJDK Community’s source code repositories from Mercurial to Git.
All single-repository OpenJDK projects would be migrated, preserving all version control history and tags. Commit messages would be reworked to adjust to the Git format, and the jcheck, webrev and defpath tools would be tweaked for the Git ecosystem too. Prototypes of these tools already exist, as does a prototype tool to translate between Mercurial and Git hashes.
But why has this come up now?
The proposal states three primary reasons for migrating to Git:
- Size of version control system metadata
- Available tooling
- Available hosting
It turns out there’s a sizable difference between Mercurial’s .hg version control metadata, which comes in around 1.2 GB, and Git’s .git directory, of around 300 MB. Smaller metadata means faster clone times and less storage being used. Add to that the fact that Git is now so ubiquitous that all text editors have Git integration (natively or with plugins), all IDEs ship with Git integration out of the box and there are lots of desktop clients to interact locally with Git repos, and it makes for a compelling argument.
It’s been almost a year since the project Skara call for discussion went out, urging the community to investigate alternative source code management options for the JDK sources. Skara’s aim was not to investigate Git, but to look into all viable alternatives. However, it was just a month ago that Skara’s tooling was made available on GitHub, so it seems fair to say that Git has edged out the competition despite skepticism from some.