Project Skara: Migrating OpenJDK to Git & GitHub

Vipul Kumar
3 min readNov 4, 2020

I’m a Software Engineer working in Java and related technologies for the past 4 years. Knowing Java is an opensource programming language a few months I got too curious about where actually the code for Java lives. I started searching for java, OpenJDK, Java8 in Github a popular version control system but none of them given the result I was looking for. I started searching for other Source Control Management tools but I was unlucky every time. Finally, I started searching on Google what scm tool is used for openjdk. It was quite hard to find the answer I was looking for but finally, I succeeded and came to know it uses Mercurial SCM.

Wait story doesn’t end here

Today again a got a bit curious let’s see what are new features coming in Java 16 by visiting the official OpenJDK website. And what I saw there below two lines-

  1. Migrate from Mercurial to Git
  2. Migrate to GitHub

Again I started exploring more and got to know about Project Skara whose whole to investigate alternative SCM and code review options for the OpenJDK source code, including options based upon Git rather than Mercurial, and including options hosted by third parties.

Objectives behind Project Skara

  1. Consolidate the JDK Forest into a Single Repository: For many years, the full code base of the JDK has been broken into numerous Mercurial repositories. In JDK 9 there are eight repositories: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn. While this model of multiple repositories offers some advantages,

2. Allow atomic commit across repositories: it also has many downsides and does a poor job of supporting various desirable source-code management operations. In particular, it is not possible to perform an atomic commit across repositories of inter-dependent changesets. For example, if the code for a single bug fix or RFE spans both the jdk and hotspot repositories today, the change to both repositories cannot be done atomically in the forest hosting those two distinct repositories.

3. Preserve all version control history, including tags
4. Reformat commit messages according to Git best practices
5. Port the jcheck, webrevand defpath tools to Git
6. Create a tool to translate between Mercurial and Git hashes etc.

Here are some resources exploring the same

Keep Learning Java!!!

--

--

Vipul Kumar

A passionate software developer working on java, spring-boot and related technologies for more than 4 years.