The effort to move the development of open source Java to GitHub is gathering steam, with the arrival of a formal proposal to migrate single-repository OpenJDK projects to the popular code-hosting platform.
The plan, formalized as part of the OpenJDK Java enhancement proposal process, would move Java’s Git repos to GitHub in concert with another proposal to migrate OpenJDK source code repos from Mercurial to Git. Both Java Development Kit (JDK) feature and update releases would be moved to GitHub, for JDK 11 and later versions.
The migration plan has been under consideration for some time, with the proliferation of Git tools and reducing the size of version control metadata cited as reasons. The new proposal, created and updated in the past week, formally refines the process to explicitly name GitHub as the target of the migration.
Moving to an external source code hosting provider can provide performance benefits, web access APIs, and an expanded community, the proposal argues. GitHub is acknowledged as the world’s largest code-hosting service and is lauded for its superior performance and extensive API in the proposal.
Goals of the formal proposal include:
- Not requiring developers to install OpenJDK-specific tools in order to contribute.
- Running pre-commit checks before every push.
- Ensuring support for workflows that are structurally similar to the existing email and webrev based workflows.
- Ensuring that the OpenJDK community can always move to a different source code hosting provider.
- Preserving and archiving all metadata.
Success metrics cited include significantly faster clone and pull times, better availability of repos, and possibilities to interact with GitHub repos via OpenJDK mailing lists, command-line tools, and browsers. There are no plans to change the OpenJDK community issue tracker, wiki, or existing infrastructure. There already is an OpenJDK presence on GitHub that includes a read-only mirror of openjdk.java.net, along with some other repos.
The proposal acknowledges that any external provider could shut down or that externally hosted source code might become unavailable. The Skara project has been put in place to mitigate such risks. Critical metadata would not be locked into one provider.