December 22, 2018

Build OpenJDK on Windows (Christmas 2018 edition)

A short description of how I build OpenJDK on Windows.

Disclaimer: This setup I have worked with and know it will work. Other variants - different toolchains, Windows versions, Visual Studio versions - may and probably will work too but are outside the scope of this document._

Topic in flux: this topic is in constant flux. For instance, there are efforts to provide a WSL based build as an addition or future replacement to Cygwin. So the information in this article may get outdated at some point.


  • Windows 7 x64 or Windows 10 x64
  • Visual Studio 2013 Professional or Visual Studio 2017 Community Edition (see Disclaimer above)

Install Cygwin

Install 64bit version of Cygwin.

The following tools are needed (beyond the base tools Cygwin installs automatically):

  • mercurial
  • diffutils
  • binutils
  • make (The GNU version)
  • m4 (Interpreters)
  • cpio
  • gawk
  • file (“file: determine file types”)
  • zip, unzip
  • procps-ng
  • autoconf, automake

The following tools may not be strictly needed but are useful if you plan to contribute patches:

  • ksh (for webrev)
  • patch, diff
  • ssh
  • wget

Note: Since updating Cygwin is cumbersome, now would be a good time to add any more tools - vim, rsync, emacs, git, … - you’d want in your setup.

Directory structure

Completely arbitrary, but this is my folder setup and the rest of the document will assume it is:

  |    |--<buildjdk, e.g. openjdk10>
  |--<repository, e.g. jdk-jdk>
               | (any number of build outputs:)

It is of course fine to use another layout - just make the mental adjustments.

Get build jdk

To build the jdk, we need a jdk.

At the time of this writing, the HEAD jdk is 13, and to build that you need JDK 11. There are a number of places to get it:

Put the downloaded and extracted JDK into openjdk/jdks.

Get sources

The official slow way: hg clone

The standard way to get the sources is to clone the corresponding mercurial repository from

Open a cygwin shell:

cd openjdk/jdk-jdk
hg clone

To follow my layout scheme, I rename the jdk to “source”:

mv jdk source

Once this is done, it may be a good idea to create a tarball from the .hg folder in case you need to resurrect the unmodified sources:

cd source
tar -czf ../jdk-source.tar .hg

Unfortunately mercurial servers at are slow. In Europe, cloning a full repository takes ~40 minutes. On Windows, this process is also plagued by timeout errors.

The faster alternative: copy sources and update

A faster alternative is to copy the repository from somewhere else and just update it. There are many ways to get a copy of the repository. One popular way is to download the source tarballs from: .

These tarballs are maintained by Aleksey Shipilev from Red Hat, thanks to him for this big time saver.

cd openjdk/jdk-jdk
tar -xf jdk-jdk.tar.xz
mv jdk-jdk source        (note: rename folder to "source")
cd source
hg pull
hg update

It is a good idea to keep Alekseys tarball around. Even if the tarball is weeks old, it is still faster to extract it and pull updates instead of re-cloning the whole directory.

Resurrecting the sources

If you later want to restore the sources from scratch, extract the source tarball and restore the repository using hg update, then pull changes using hg pull -u.


Open the cygwin shell. Create output directory:

mkdir openjdk/jdk-jdk/output
cd openjdk/jdk-jdk/output

Run configure:


bash ../source/configure --with-boot-jdk=/cygdrive/c/openjdk/jdks/jdk10 --with-debug-level=fastdebug


bash ../source/configure --with-boot-jdk=/cygdrive/c/openjdk/jdks/jdk10 --with-debug-level=release

(Note: boot jdk path has to be absolute due to a bug in configure.)

Run make:

make images

Tips and Tricks

Re-run configure and rebuild from scratch without having to reissue the configure command:

make reconfigure clean images

Build 32bit:


Build Non-PCH:


Choose which Visual Studio installation to use:


Check which configure options a build was built with:


Speed up builds: During builds, the JDK being created is also used - to run jmod.exe, jlink.exe and other tools which need a close knowledge of the JDK source level to work correctly.

But this means that if you build naturally slow JDK variants (e.g. zero and slowdebug), the build itself can become slow. To counter that, one can specify a separate build JDK which is used instead of the just-built JDK.

--with-build-jdk=<path to hopefully fast build jdk>

Warning: In contrast to the boot jdk, this JDK has to be close to the sources! A good practice would be to use a release build of the same source tree and source level.