JEP 296: Consolidate the JDK Sources into a Single Repository

July 17, 2019 | 1 minute read
Text Size 100%:

Download a PDF of this article

This proposal, which was implemented in Java 10, illustrates some of the difficulties in maintaining a codebase that has the specific requirements of the JDK. Specifically, this JEP addresses the following problem: many code commits span several of the individual repositories in the source base. Consequently, it’s not possible to make atomic commits to the source code manager. (When speaking of a commit, “atomic” means that the action is carried out in its entirety as a single operation—or not at all.) Clearly, if a commit must be done separately to several repositories to be complete, there is no possibility of atomicity. This means that every commit is labor-intensive and fragile until completed.

In the JDK, there are eight principal repositories, and roughly 1,100 defects and requests span more than one of them. So this JEP proposed merging these repositories into a single repository.

The advantages of a central, single repository are increasingly being recognized by companies that have large codebases. For example, Google and Facebook have frequently broadcast their use of a single, monolithic repository for all their products’ code. The Google repository, which contains more than 2 billion lines of code, has reportedly generated several advantages: unified versioning, simplified code sharing, and greater reuse. Invariably, this JEP will require changes to internal development practices and DevOps. Should those changes have value to Java developers at large, we’ll report on them in the future.

All current and former JEPs can be found on the Oracle Open JDK site.

Java Magazine Staff

Java Magazine staff (javamag_us@oracle.com, @Oraclejavamag) deliver authoritative information about Java, the JVM, and JVM languages to a community of more than one-quarter million developers.


Previous Post

Creating Your Own Debugging Tools

Andrei Pangin | 11 min read

Next Post


JEP 335: Deprecate the Nashorn JavaScript Engine

Java Magazine Staff | 2 min read