% Building the JDK

## TL;DR (Instructions for the Impatient)

If you are eager to try out building the JDK, these simple steps works most of

the time. They assume that you have installed Mercurial (and Cygwin if running

on Windows) and cloned the top-level JDK repository that you want to build.

 1. [Get the complete source code](#getting-the-source-code): \

    `hg clone http://hg.openjdk.java.net/jdk/jdk`

 2. [Run configure](#running-configure): \

    `bash configure`

    If `configure` fails due to missing dependencies (to either the

    [toolchain](#native-compiler-toolchain-requirements), [build tools](

    #build-tools-requirements), [external libraries](

    #external-library-requirements) or the [boot JDK](#boot-jdk-requirements)),

    most of the time it prints a suggestion on how to resolve the situation on

    your platform. Follow the instructions, and try running `bash configure`

    again.

 3. [Run make](#running-make): \

    `make images`

 4. Verify your newly built JDK: \

    `./build/*/images/jdk/bin/java -version`

 5. [Run basic tests](##running-tests): \

    `make run-test-tier1`

If any of these steps failed, or if you want to know more about build

requirements or build functionality, please continue reading this document.

## Introduction

The JDK is a complex software project. Building it requires a certain amount of

technical expertise, a fair number of dependencies on external software, and

reasonably powerful hardware.

If you just want to use the JDK and not build it yourself, this document is not

for you. See for instance [OpenJDK installation](

http://openjdk.java.net/install) for some methods of installing a prebuilt

JDK.

## Getting the Source Code

Make sure you are getting the correct version. As of JDK 10, the source is no

longer split into separate repositories so you only need to clone one single

repository. At the [OpenJDK Mercurial server](http://hg.openjdk.java.net/) you

can see a list of all available repositories. If you want to build an older version,

e.g. JDK 8, it is recommended that you get the `jdk8u` forest, which contains

incremental updates, instead of the `jdk8` forest, which was frozen at JDK 8 GA.

If you are new to Mercurial, a good place to start is the [Mercurial Beginner's

Guide](http://www.mercurial-scm.org/guide). The rest of this document assumes a

working knowledge of Mercurial.

### Special Considerations

For a smooth building experience, it is recommended that you follow these rules

on where and how to check out the source code.

  * Do not check out the source code in a path which contains spaces. Chances

    are the build will not work. This is most likely to be an issue on Windows

    systems.

  * Do not check out the source code in a path which has a very long name or is

    nested many levels deep. Chances are you will hit an OS limitation during

    the build.

  * Put the source code on a local disk, not a network share. If possible, use

    an SSD. The build process is very disk intensive, and having slow disk

    access will significantly increase build times. If you need to use a

    network share for the source code, see below for suggestions on how to keep

    the build artifacts on a local disk.

  * On Windows, if using [Cygwin](#cygwin), extra care must be taken to make sure

    the environment is consistent. It is recommended that you follow this

    procedure:

      * Create the directory that is going to contain the top directory of the

        JDK clone by using the `mkdir` command in the Cygwin bash shell.

        That is, do *not* create it using Windows Explorer. This will ensure

        that it will have proper Cygwin attributes, and that it's children will

        inherit those attributes.

      * Do not put the JDK clone in a path under your Cygwin home

        directory. This is especially important if your user name contains

        spaces and/or mixed upper and lower case letters.

      * Clone the JDK repository using the Cygwin command line `hg` client

        as instructed in this document. That is, do *not* use another Mercurial

        client such as TortoiseHg.

    Failure to follow this procedure might result in hard-to-debug build

    problems.

## Build Hardware Requirements

The JDK is a massive project, and require machines ranging from decent to

powerful to be able to build in a reasonable amount of time, or to be able to

complete a build at all.

We *strongly* recommend usage of an SSD disk for the build, since disk speed is

one of the limiting factors for build performance.

### Building on x86

At a minimum, a machine with 2-4 cores is advisable, as well as 2-4 GB of RAM.

(The more cores to use, the more memory you need.) At least 6 GB of free disk

space is required (8 GB minimum for building on Solaris).

Even for 32-bit builds, it is recommended to use a 64-bit build machine, and

instead create a 32-bit target using `--with-target-bits=32`.

### Building on sparc

At a minimum, a machine with 4 cores is advisable, as well as 4 GB of RAM. (The

more cores to use, the more memory you need.) At least 8 GB of free disk space

is required.

### Building on aarch64

At a minimum, a machine with 8 cores is advisable, as well as 8 GB of RAM.

(The more cores to use, the more memory you need.) At least 6 GB of free disk

space is required.

If you do not have access to sufficiently powerful hardware, it is also

possible to use [cross-compiling](#cross-compiling).

### Building on 32-bit arm

This is not recommended. Instead, see the section on [Cross-compiling](

#cross-compiling).

## Operating System Requirements

The mainline JDK project supports Linux, Solaris, macOS, AIX and Windows.

Support for other operating system, e.g. BSD, exists in separate "port"

projects.

In general, the JDK can be built on a wide range of versions of these operating

systems, but the further you deviate from what is tested on a daily basis, the

more likely you are to run into problems.

This table lists the OS versions used by Oracle when building the JDK. Such

information is always subject to change, but this table is up to date at the

time of writing.

 Operating system   Vendor/version used

 -----------------  -------------------------------------------------------

 Linux              Oracle Enterprise Linux 6.4 / 7.6

 Solaris            Solaris 11.3 SRU 20

 macOS              Mac OS X 10.13 (High Sierra)

 Windows            Windows Server 2012 R2

The double version numbers for Linux and Solaris are due to the hybrid model

used at Oracle, where header files and external libraries from an older version

are used when building on a more modern version of the OS.

The Build Group has a wiki page with [Supported Build Platforms](

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms). From

time to time, this is updated by contributors to list successes or failures of

building on different platforms.

### Windows

Windows XP is not a supported platform, but all newer Windows should be able to

build the JDK.

On Windows, it is important that you pay attention to the instructions in the

[Special Considerations](#special-considerations).

Windows is the only non-POSIX OS supported by the JDK, and as such, requires

some extra care. A POSIX support layer is required to build on Windows.

Currently, the only supported such layers are Cygwin and Windows Subsystem for

Linux (WSL). (Msys is no longer supported due to a too old bash; msys2 would

likely be possible to support in a future version but that would require effort

to implement.)

Internally in the build system, all paths are represented as Unix-style paths,

e.g. `/cygdrive/c/hg/jdk9/Makefile` rather than `C:\hg\jdk9\Makefile`. This

rule also applies to input to the build system, e.g. in arguments to

`configure`. So, use `--with-msvcr-dll=/cygdrive/c/msvcr100.dll` rather than

`--with-msvcr-dll=c:\msvcr100.dll`. For details on this conversion, see the section

on [Fixpath](#fixpath).

#### Cygwin

A functioning [Cygwin](http://www.cygwin.com/) environment is required for

building the JDK on Windows. If you have a 64-bit OS, we strongly recommend

using the 64-bit version of Cygwin.

**Note:** Cygwin has a model of continuously updating all packages without any

easy way to install or revert to a specific version of a package. This means

that whenever you add or update a package in Cygwin, you might (inadvertently)

update tools that are used by the JDK build process, and that can cause

unexpected build problems.

The JDK requires GNU Make 4.0 or greater in Cygwin. This is usually not a

problem, since Cygwin currently only distributes GNU Make at a version above

4.0.

Apart from the basic Cygwin installation, the following packages must also be

installed:

  * `autoconf`

  * `make`

  * `zip`

  * `unzip`

Often, you can install these packages using the following command line:

```

<path to Cygwin setup>/setup-x86_64 -q -P autoconf -P make -P unzip -P zip

```

Unfortunately, Cygwin can be unreliable in certain circumstances. If you

experience build tool crashes or strange issues when building on Windows,

please check the Cygwin FAQ on the ["BLODA" list](

https://cygwin.com/faq/faq.html#faq.using.bloda) and the section on [fork()

failures](https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures).

#### Windows Subsystem for Linux (WSL)

Windows 10 1809 or newer is supported due to a dependency on the wslpath utility

and support for environment variable sharing through WSLENV. Version 1803 can

work but intermittent build failures have been observed.

It's possible to build both Windows and Linux binaries from WSL. To build

Windows binaries, you must use a Windows boot JDK (located in a

Windows-accessible directory). To build Linux binaries, you must use a Linux

boot JDK. The default behavior is to build for Windows. To build for Linux, pass

`--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu` to

`configure`.

If building Windows binaries, the source code must be located in a Windows-

accessible directory. This is because Windows executables (such as Visual Studio

and the boot JDK) must be able to access the source code. Also, the drive where

the source is stored must be mounted as case-insensitive by changing either

/etc/fstab or /etc/wsl.conf in WSL. Individual directories may be corrected

using the fsutil tool in case the source was cloned before changing the mount

options.

Note that while it's possible to build on WSL, testing is still not fully

supported.

### Solaris

See `make/devkit/solaris11.1-package-list.txt` for a list of recommended

packages to install when building on Solaris. The versions specified in this

list is the versions used by the daily builds at Oracle, and is likely to work

properly.

Older versions of Solaris shipped a broken version of `objcopy`. At least

version 2.21.1 is needed, which is provided by Solaris 11 Update 1. Objcopy is

needed if you want to have external debug symbols. Please make sure you are

using at least version 2.21.1 of objcopy, or that you disable external debug

symbols.

### macOS

Apple is using a quite aggressive scheme of pushing OS updates, and coupling

these updates with required updates of Xcode. Unfortunately, this makes it

difficult for a project such as the JDK to keep pace with a continuously updated

machine running macOS. See the section on [Apple Xcode](#apple-xcode) on some

strategies to deal with this.

It is recommended that you use at least Mac OS X 10.13 (High Sierra). At the time

of writing, the JDK has been successfully compiled on macOS 10.12 (Sierra).

The standard macOS environment contains the basic tooling needed to build, but

for external libraries a package manager is recommended. The JDK uses

[homebrew](https://brew.sh/) in the examples, but feel free to use whatever

manager you want (or none).

### Linux

It is often not much problem to build the JDK on Linux. The only general advice

is to try to use the compilers, external libraries and header files as provided

by your distribution.

The basic tooling is provided as part of the core operating system, but you

will most likely need to install developer packages.

For apt-based distributions (Debian, Ubuntu, etc), try this:

```

sudo apt-get install build-essential

```

For rpm-based distributions (Fedora, Red Hat, etc), try this:

```

sudo yum groupinstall "Development Tools"

```

### AIX

Please consult the AIX section of the [Supported Build Platforms](

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK

Build Wiki page for details about which versions of AIX are supported.

## Native Compiler (Toolchain) Requirements

Large portions of the JDK consists of native code, that needs to be compiled to

be able to run on the target platform. In theory, toolchain and operating

system should be independent factors, but in practice there's more or less a

one-to-one correlation between target operating system and toolchain.

 Operating system   Supported toolchain

 ------------------ -------------------------

 Linux              gcc, clang

 macOS              Apple Xcode (using clang)

 Solaris            Oracle Solaris Studio

 AIX                IBM XL C/C++

 Windows            Microsoft Visual Studio

Please see the individual sections on the toolchains for version

recommendations. As a reference, these versions of the toolchains are used, at

the time of writing, by Oracle for the daily builds of the JDK. It should be

possible to compile the JDK with both older and newer versions, but the closer

you stay to this list, the more likely you are to compile successfully without

issues.

 Operating system   Toolchain version

 ------------------ -------------------------------------------------------

 Linux              gcc 8.2.0

 macOS              Apple Xcode 10.1 (using clang 10.0.0)

 Solaris            Oracle Solaris Studio 12.6 (with compiler version 5.15)

 Windows            Microsoft Visual Studio 2017 update 15.9.6

All compilers are expected to be able to compile to the C99 language standard,

as some C99 features are used in the source code. Microsoft Visual Studio

doesn't fully support C99 so in practice shared code is limited to using C99

features that it does support.

### gcc

The minimum accepted version of gcc is 4.8. Older versions will generate a warning

by `configure` and are unlikely to work.

The JDK is currently known to be able to compile with at least version 7.4 of

gcc.

In general, any version between these two should be usable.

### clang

The minimum accepted version of clang is 3.2. Older versions will not be

accepted by `configure`.

To use clang instead of gcc on Linux, use `--with-toolchain-type=clang`.

### Apple Xcode

The oldest supported version of Xcode is 8.

You will need the Xcode command lines developers tools to be able to build

the JDK. (Actually, *only* the command lines tools are needed, not the IDE.)

The simplest way to install these is to run:

```

xcode-select --install

```

It is advisable to keep an older version of Xcode for building the JDK when

updating Xcode. This [blog page](

http://iosdevelopertips.com/xcode/install-multiple-versions-of-xcode.html) has

good suggestions on managing multiple Xcode versions. To use a specific version

of Xcode, use `xcode-select -s` before running `configure`, or use

`--with-toolchain-path` to point to the version of Xcode to use, e.g.

`configure --with-toolchain-path=/Applications/Xcode8.app/Contents/Developer/usr/bin`

If you have recently (inadvertently) updated your OS and/or Xcode version, and

the JDK can no longer be built, please see the section on [Problems with the

Build Environment](#problems-with-the-build-environment), and [Getting

Help](#getting-help) to find out if there are any recent, non-merged patches

available for this update.

### Oracle Solaris Studio

The minimum accepted version of the Solaris Studio compilers is 5.13

(corresponding to Solaris Studio 12.4). Older versions will not be accepted by

configure.

The Solaris Studio installation should contain at least these packages:

 Package                                            Version

 -------------------------------------------------- -------------

 developer/solarisstudio-124/backend                12.4-1.0.6.0

 developer/solarisstudio-124/c++                    12.4-1.0.10.0

 developer/solarisstudio-124/cc                     12.4-1.0.4.0

 developer/solarisstudio-124/library/c++-libs       12.4-1.0.10.0

 developer/solarisstudio-124/library/math-libs      12.4-1.0.0.1

 developer/solarisstudio-124/library/studio-gccrt   12.4-1.0.0.1

 developer/solarisstudio-124/studio-common          12.4-1.0.0.1

 developer/solarisstudio-124/studio-ja              12.4-1.0.0.1

 developer/solarisstudio-124/studio-legal           12.4-1.0.0.1

 developer/solarisstudio-124/studio-zhCN            12.4-1.0.0.1

Compiling with Solaris Studio can sometimes be finicky. This is the exact

version used by Oracle, which worked correctly at the time of writing:

```

$ cc -V

cc: Sun C 5.13 SunOS_i386 2014/10/20

$ CC -V

CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30

```

### Microsoft Visual Studio

The minimum accepted version of Visual Studio is 2010. Older versions will not

be accepted by `configure`. The maximum accepted version of Visual Studio is

2019. Versions older than 2017 are unlikely to continue working for long.

If you have multiple versions of Visual Studio installed, `configure` will by

default pick the latest. You can request a specific version to be used by

setting `--with-toolchain-version`, e.g. `--with-toolchain-version=2015`.

If you get `LINK: fatal error LNK1123: failure during conversion to COFF: file

invalid` when building using Visual Studio 2010, you have encountered

[KB2757355](http://support.microsoft.com/kb/2757355), a bug triggered by a

specific installation order. However, the solution suggested by the KB article

does not always resolve the problem. See [this stackoverflow discussion](

https://stackoverflow.com/questions/10888391) for other suggestions.

### IBM XL C/C++

Please consult the AIX section of the [Supported Build Platforms](

https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) OpenJDK

Build Wiki page for details about which versions of XLC are supported.

## Boot JDK Requirements

Paradoxically, building the JDK requires a pre-existing JDK. This is called the

"boot JDK". The boot JDK does not, however, have to be a JDK built directly from

the source code available in the OpenJDK Community.  If you are porting the JDK

to a new platform, chances are that there already exists another JDK for that

platform that is usable as boot JDK.

The rule of thumb is that the boot JDK for building JDK major version *N*

should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 would be

suitable as boot JDK. However, the JDK should be able to "build itself", so an

up-to-date build of the current JDK source is an acceptable alternative. If

you are following the *N-1* rule, make sure you've got the latest update

version, since JDK 8 GA might not be able to build JDK 9 on all platforms.

Early in the release cycle, version *N-1* may not yet have been released. In

that case, the preferred boot JDK will be version *N-2* until version *N-1*

is available.

If the boot JDK is not automatically detected, or the wrong JDK is picked, use

`--with-boot-jdk` to point to the JDK to use.

### Getting JDK binaries

JDK binaries for Linux, Windows and macOS can be downloaded from

[jdk.java.net](http://jdk.java.net). An alternative is to download the

[Oracle JDK](http://www.oracle.com/technetwork/java/javase/downloads). Another

is the [Adopt OpenJDK Project](https://adoptopenjdk.net/), which publishes

experimental prebuilt binaries for various platforms.

On Linux you can also get a JDK from the Linux distribution. On apt-based

distros (like Debian and Ubuntu), `sudo apt-get install openjdk-<VERSION>-jdk`

is typically enough to install a JDK \<VERSION\>. On rpm-based distros (like

Fedora and Red Hat), try `sudo yum install java-<VERSION>-openjdk-devel`.

## External Library Requirements

Different platforms require different external libraries. In general, libraries

are not optional - that is, they are either required or not used.

If a required library is not detected by `configure`, you need to provide the

path to it. There are two forms of the `configure` arguments to point to an

external library: `--with-<LIB>=<path>` or `--with-<LIB>-include=<path to

include> --with-<LIB>-lib=<path to lib>`. The first variant is more concise,

but require the include files an library files to reside in a default hierarchy

under this directory. In most cases, it works fine.

As a fallback, the second version allows you to point to the include directory

and the lib directory separately.

### FreeType

FreeType2 from [The FreeType Project](http://www.freetype.org/) is not required

on any platform. The exception is on Unix-based platforms when configuring such

that the build artifacts will reference a system installed library,

rather than bundling the JDK’s own copy.