If you are eager to try out building OpenJDK, 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 OpenJDK repository that you want to build.
Get the complete source code:
-hg clone http://hg.openjdk.java.net/jdk10/master
hg clone http://hg.openjdk.java.net/jdk/jdkRun configure:
bash configure
If configure fails due to missing dependencies (to either the toolchain, external libraries or the boot JDK), 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.
If configure fails due to missing dependencies (to either the toolchain, build tools, external libraries or the boot JDK), 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.
Run make:
make images
Verify your newly built JDK:
@@ -201,12 +201,13 @@
OpenJDK requires GNU Make 4.0 or greater on Windows. 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:
autoconfmakezipunzipOften, you can install these packages using the following command line:
-<path to Cygwin setup>/setup-x86_64 -q -P make -P unzip -P zip<path to Cygwin setup>/setup-x86_64 -q -P autoconf -P make -P unzip -P zipUnfortunately, 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 and the section on fork() failures.
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.
sudo yum install libffi-devel.Use --with-libffi=<path> if configure does not properly locate your libffi files.
OpenJDK requires Autoconf on all platforms. At least version 2.69 is required.
+sudo apt-get install autoconf.sudo yum install autoconf.brew install autoconf.<path to Cygwin setup>/setup-x86_64 -q -P autoconf.If configure has problems locating your installation of autoconf, you can specify it using the AUTOCONF environment variable, like this:
AUTOCONF=<path to autoconf> configure ...OpenJDK requires GNU Make. No other flavors of make are supported.
At least version 3.81 of GNU Make must be used. For distributions supporting GNU Make 4.0 or above, we strongly recommend it. GNU Make 4.0 contains useful functionality to handle parallel building (supported by --with-output-sync) and speed and stability improvements.
OpenJDK requires GNU Bash. No other shells are supported.
At least version 3.2 of GNU Bash must be used.
-If you want to modify the build system itself, you need to install Autoconf.
-However, if you only need to build OpenJDK or if you only edit the actual OpenJDK source files, there is no dependency on autoconf, since the source distribution includes a pre-generated configure shell script.
See the section on Autoconf Details for details on how OpenJDK uses autoconf. This is especially important if you plan to contribute changes to OpenJDK that modifies the build system.
To build OpenJDK, you need a "configuration", which consists of a directory where to store the build output, coupled with information about the platform, the specific build machine, and choices that affect how OpenJDK is built.
The configuration is created by the configure script. The basic invocation of the configure script looks like this:
This can be a sign of a Cygwin problem. See the information about solving problems in the Cygwin section. Rebooting the computer might help temporarily.
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 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 . Please include the relevant parts of the configure and/or build log.
If you need general help or advice about developing for OpenJDK, you can also contact the Adoption Group. See the section on Contributing to OpenJDK for more information.
When building for distribution, zipped is a good solution. Binaries built with internal is suitable for use by developers, since they facilitate debugging, but should be stripped before distributed to end users.
The configure script is based on the autoconf framework, but in some details deviate from a normal autoconf configure script.
The configure script in the top level directory of OpenJDK is just a thin wrapper that calls make/autoconf/configure. This in turn provides functionality that is not easily expressed in the normal Autoconf framework, and then calls into the core of the configure script, which is the make/autoconf/generated-configure.sh file.
As the name implies, this file is generated by Autoconf. It is checked in after regeneration, to alleviate the common user to have to install Autoconf.
-The build system will detect if the Autoconf source files have changed, and will trigger a regeneration of make/autoconf/generated-configure.sh if needed. You can also manually request such an update by bash make/autoconf/autogen.sh.
If you make changes to the build system that requires a re-generation, note the following:
-You must use exactly version 2.69 of autoconf for your patch to be accepted. This is to avoid spurious changes in the generated file. Note that Ubuntu 16.04 ships a patched version of autoconf which claims to be 2.69, but is not.
You do not need to include the generated file in reviews.
If the generated file needs updating, the Oracle JDK closed counter-part will also need to be updated. It is very much appreciated if you ask for an Oracle engineer to sponsor your push so this can be made in tandem.
The configure script in the top level directory of OpenJDK is just a thin wrapper that calls make/autoconf/configure. This in turn will run autoconf to create the runnable (generated) configure script, as .build/generated-configure.sh. Apart from being responsible for the generation of the runnable script, the configure script also provides functionality that is not easily expressed in the normal Autoconf framework. As part of this functionality, the generated script is called.
The build system will detect if the Autoconf source files have changed, and will trigger a regeneration of the generated script if needed. You can also manually request such an update by bash configure autogen.
In previous versions of the OpenJDK, the generated script was checked in at make/autoconf/generated-configure.sh. This is no longer the case.
This section contains a few remarks about how to develop for the build system itself. It is not relevant if you are only making changes in the product source code.
While technically using make, the make source files of the OpenJDK does not resemble most other Makefiles. Instead of listing specific targets and actions (perhaps using patterns), the basic modus operandi is to call a high-level function (or properly, macro) from the API in make/common. For instance, to compile all classes in the jdk.internal.foo package in the jdk.foo module, a call like this would be made:
make COMPARE_BUILD=CONF=--enable-new-hotspot-feature:MAKE=hotspotSee make/InitSupport.gmk for details on how to use COMPARE_BUILD.
To analyze build performance, run with LOG=trace and check $BUILD/build-trace-time.log. Use JOBS=1 to avoid parallelism.
Please check that you adhere to the Code Conventions for the Build System before submitting patches. Also see the section in Autoconf Details about the generated configure script.
+Please check that you adhere to the Code Conventions for the Build System before submitting patches.
So, now you've build your OpenJDK, and made your first patch, and want to contribute it back to the OpenJDK community.
First of all: Thank you! We gladly welcome your contribution to the OpenJDK. However, please bear in mind that OpenJDK is a massive project, and we must ask you to follow our rules and guidelines to be able to accept your contribution.