Java 16 Commits to Git and GitHub: A Personal Reflection

A Stroll Down Memory Lane

I was introduced to Git and GitHub in May of 2014 – just shy of 10 years since Git was created in 2005. That same day I was also handed a MacBook Pro laptop and an IntelliJ license, the main tools with which I was to begin my new role as a developer in a new position at a new company. It all sounds lovely, right?

In all the excitement and promise of grand opportunities and a new journey in my career, I was careful not to let my fear distort my expression of gratitude. You see, I didn’t expect all of this “newness.” In fact, in my mind at that moment, my plans to knock it out of the park on my first day were dashed. There were three simple reasons for this. First, I was a loyal Windows user. There were a few times my eyes wandered to a colleague’s Mac display, but that was it – nothing further. The second reason was that I was accustomed to using Eclipse as my primary IDE. IntelliJ was a completely new animal to me. And third, the only source control management system I was familiar with at that time was Apache Subversion (aka SVN).

Today, I’m still using a MacBook Pro, IntelliJ, and of course, Git and GitHub, and I’m grateful to have had the exposure to this toolset. This is not meant to be a statement that any of these tools are better than what I was using before. In this case, it was more about what was going to make me more productive and efficient in my new position. And given that these were the development tools my new team had settled on prior to my arrival, the consistency in the toolset resulted in making the ramp up of getting my environment set up a breeze. There were step by step, up-to-date instructions for setting up the projects I would be working on, and I had the support of my peers if any questions arose. The use of these tools became second nature, and since then, there hasn’t been a requirement for me to use anything different other than a project here and there that used a different source control system (which was super annoying).

Java 16 Gits With The Program

All of these memories I’ve shared came flooding to my mind when I read the related JDK Enhancement Proposals for the new Java 16 release. JEP 357 describes the process of migrating the OpenJDK community’s source code repositories from Mercurial to Git. JEP 369 describes the migration to GitHub to host these repositories. 

If you’re not familiar with how OpenJDK is developed or haven’t been involved in contributing to the project, it might be news to you that for all of this time, OpenJDK was in fact backed by Mercurial repositories! Although popular in it’s day, times have certainly changed in the world of version control systems.

One could argue that Java was late to the show considering Git’s popularity and widespread usage among developers and other open source communities. The Google Trend Analysis from 2004 to the end of 2020 is pretty revealing in this regard, showing the rapid growth of the popularity of Git, surpassing the popularity of SVN around 2011, with Mercurial and Concurrent Versions System (CVS) consistently hovering at low values in comparison.

Source: Google Trends

If You Build It, They Will Come

There were several motivations behind the move to Git and GitHub, including but not limited to:

• Preserving disk space and improved clone times when using Git vs Mercurial (according to JEP 357, “the .git directory of the jdk/jdk repository is approximately 300 MB with Git and the .hg directory is around 1.2 GB with Mercurial”) 
• Impressive performance measures and popularity of the GitHub hosting service (serving 50 million users as of May, 2020)
• The availability of an extensive API offered by GitHub that improves the development and review process of change sets (no more resorting to mailing lists alone for collaboration with contributors)

One of the motivations for using an external hosting provider like GitHub that stood out to me the most was this – directly from JEP 369: 

“… the opportunity to tap into large existing communities of developers and potential contributors.”

This was not a decision made in haste or in a vacuum. There was careful consideration to how this move would affect the workflow of existing developers as well as future potential contributors. There were thoughtful decisions made to preserve as much of the existing workflow as possible in order to keep experienced contributors productive while enabling other workflows that future developers would prefer. Developers that may have been hindered from by the OpenJDK specific toolset previously, may now more easily turn into potential contributors using tools they are familiar and comfortable with.

Given all of the tools we have available to us today that integrate with Git and GitHub — the most popular text editors, the most popular IDEs, and a number of desktop clients — it just makes sense!

No Pain, No Gain

I won’t lie. Those first couple of weeks in my position with new development tools were rough. I had been in my career long enough by then to have developed quite a stash of shortcuts and productivity hacks using the tools I knew best. You know that discomfort that comes with driving someone else’s car? — that moment of anxiety when you realize that the brakes respond differently than you’re used to? Or when you’re frantically looking for how to start the windshield wipers? Multiply that feeling by at least ten! My muscle memory had me incessantly typing keys and using shortcuts that didn’t exist or erroneously using SVN commands instead of Git commands. I remember spending my first night with the new laptop watching videos on how to use a Mac. Good times… and totally worth it!

As is typical when moving to a new development team, I also had to get up to speed on the development process they were using. This was when I was introduced to the GitHub Pull Request (PR) process. Contributors to OpenJDK will now go through this same process – reviewing proposed changes via a PR. 

After automated checks are done to verify the validity of the changes and an email is automatically generated to the appropriate mailing lists to indicate the PR is ready for review, the GitHub API capabilities make it possible for contributors to interact with the PR in several different ways. A reviewer can use the review tool with their browser on https://github.com/; via the GitHub integration tools of their favorite text editor, IDE, or desktop application; or by command line using tooling developed in Project Skara. A user actually doesn’t even need a GitHub account to interact with the PR via the associated mailing list! — comments from the mailing list are added to the PR and are reflected in all other workflows.

Much time and effort has been committed to make this process as painless as possible with the hope to encourage MORE collaboration among contributors and perhaps even attract more contributions and collaboration from the huge developer community that already enjoys the conveniences that GitHub provides. Given my experiences with changing up my development tooling and workflow in the past, I fully appreciate how important it is to keep the process as smooth as possible. I also understand why the move has taken this long — this is an incredible feat.

Conclusion – The Power of Choice

I look forward to seeing the success of the Java 16 release, with OpenJDK using Git repositories hosted on GitHub. I’m convinced that one of the primary reasons this WILL be successful in the context of growing the contributor base of OpenJDK is that a lot of blockers regarding the tooling have been removed. Because of the popularity of Git and GitHub, many developers already have an account and are familiar with how to use it. They are no longer required to set up any OpenJDK specific tools or bear the cognitive load of learning to use something they don’t already use regularly (sorry, Mercurial).

It also can’t be overstated how much developing integrations with the tools that developers already use played a huge role in the success GitHub has enjoyed thus far and in the decision to use GitHub as the external hosting provider for OpenJDK. 

This ‘open’ mentality reminds me of JFrog’s efforts to integrate with the tools that DevOps teams already use. For example, JFrog Pipelines can utilize the available GitHub integration to trigger builds for CI/CD pipelines with repositories in GitHub, and JFrog Artifactory supports managing large source files as binaries using Git Large File Storage (LFS) repositories.

We put time and effort into our development and operations workflows, and when these are already based on best practices, the best improvements are the ones that fit seamlessly into our existing processes without causing headaches for everyone involved. Time will tell if this move accomplishes all that JEP 357 and JEP 369 hoped to achieve. In the meantime, a toast to the Java 16 release and its new relationship with Git and GitHub is in order!

Read more about how the Java 16 release improves the packaging of Java artifacts in this blog post:
In Java 16 Release jpackage is Production Ready

Java^® is a registered trademark of Oracle and/or its affiliates.