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 for some methods of installing a prebuilt JDK.
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 you can see a list of all available forests. 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.
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 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. The rest of this document assumes a working knowledge of Mercurial.
For a smooth building experience, it is recommended that you follow these rules on where and how to check out the source code.
@@ -780,11 +780,11 @@Verify that the summary at the end looks correct. Are you indeed using the Boot JDK and native toolchain that you expect?
By default, the JDK has a strict approach where warnings from the compiler is considered errors which fail the build. For very new or very old compiler versions, this can trigger new classes of warnings, which thus fails the build. Run configure with --disable-warnings-as-errors to turn of this behavior. (The warnings will still show, but not make the build fail.)
Incremental rebuilds mean that when you modify part of the product, only the affected parts get rebuilt. While this works great in most cases, and significantly speed up the development process, from time to time complex interdependencies will result in an incorrect build result. This is the most common cause for unexpected build problems, together with inconsistencies between the different Mercurial repositories in the forest.
+Incremental rebuilds mean that when you modify part of the product, only the affected parts get rebuilt. While this works great in most cases, and significantly speed up the development process, from time to time complex interdependencies will result in an incorrect build result. This is the most common cause for unexpected build problems.
Here are a suggested list of things to try if you are having unexpected build problems. Each step requires more time than the one before, so try them in order. Most issues will be solved at step 1 or 2.
Make sure your forest is up-to-date
-Run bash get_source.sh to make sure you have the latest version of all repositories.
Make sure your repository is up-to-date
+Run hg pull -u to make sure you have the latest changes.
Clean build results
The simplest way to fix incremental rebuild issues is to run make clean. This will remove all build results, but not the configuration or any build system support artifacts. In most cases, this will solve build errors resulting from incremental build mismatches.
Completely clean the build directory.
@@ -793,8 +793,8 @@ make dist-clean bash configure $(cat current-configuration) makeRe-clone the Mercurial forest
-Sometimes the Mercurial repositories themselves gets in a state that causes the product to be un-buildable. In such a case, the simplest solution is often the "sledgehammer approach": delete the entire forest, and re-clone it. If you have local changes, save them first to a different location using hg export.
Re-clone the Mercurial repository
+Sometimes the Mercurial repository gets in a state that causes the product to be un-buildable. In such a case, the simplest solution is often the "sledgehammer approach": delete the entire repository, and re-clone it. If you have local changes, save them first to a different location using hg export.
If none of the suggestions in this document helps you, or if you find what you believe is a bug in the build system, please contact the Build Group by sending a mail to build-dev@openjdk.java.net. Please include the relevant parts of the configure and/or build log.
If you need general help or advice about developing for the JDK, you can also contact the Adoption Group. See the section on Contributing to OpenJDK for more information.
To help you prepare a proper push path for a Mercurial repository, there exists a useful tool known as defpath. It will help you setup a proper push path for pushing changes to the JDK.
Install the extension by cloning http://hg.openjdk.java.net/code-tools/defpath and updating your .hgrc file. Here's one way to do this:
cd ~
@@ -829,7 +829,6 @@
EOTYou can now setup a proper push path using:
hg defpath -d -u <your OpenJDK username>If you also have the trees extension installed in Mercurial, you will automatically get a tdefpath command, which is even more useful. By running hg tdefpath -du <username> in the top repository of your forest, all repos will get setup automatically. This is the recommended usage.
The configure and make commands tries to play nice with bash command-line completion (using <tab> or <tab><tab>). To use this functionality, make sure you enable completion in your ~/.bashrc (see instructions for bash in your operating system).
Make completion will work out of the box, and will complete valid make targets. For instance, typing make jdk-i<tab> will complete to make jdk-image.
Now configure --en<tab>-dt<tab> will result in configure --enable-dtrace.
You can have multiple configurations for a single source forest. When you create a new configuration, run configure --with-conf-name=<name> to create a configuration with the name <name>. Alternatively, you can create a directory under build and run configure from there, e.g. mkdir build/<name> && cd build/<name> && bash ../../configure.
You can have multiple configurations for a single source repository. When you create a new configuration, run configure --with-conf-name=<name> to create a configuration with the name <name>. Alternatively, you can create a directory under build and run configure from there, e.g. mkdir build/<name> && cd build/<name> && bash ../../configure.
Then you can build that configuration using make CONF_NAME=<name> or make CONF=<pattern>, where <pattern> is a substring matching one or several configurations, e.g. CONF=debug. The special empty pattern (CONF=) will match all available configuration, so make CONF= hotspot will build the hotspot target for all configurations. Alternatively, you can execute make in the configuration directory, e.g. cd build/<name> && make.
If you update the forest and part of the configure script has changed, the build system will force you to re-run configure.
If you update the repository and part of the configure script has changed, the build system will force you to re-run configure.
Most of the time, you will be fine by running configure again with the same arguments as the last time, which can easily be performed by make reconfigure. To simplify this, you can use the CONF_CHECK make control variable, either as make CONF_CHECK=auto, or by setting an environment variable. For instance, if you add export CONF_CHECK=auto to your .bashrc file, make will always run reconfigure automatically whenever the configure script has changed.
You can also use CONF_CHECK=ignore to skip the check for a needed configure update. This might speed up the build, but comes at the risk of an incorrect build result. This is only recommended if you know what you're doing.
From time to time, you will also need to modify the command line to configure due to changes. Use make print-configure to show the command line used for your current configuration.