< prev index next >
doc/building.html
Print this page
*** 54,67 ****
<li><a href="#cups">CUPS</a></li>
<li><a href="#x11">X11</a></li>
<li><a href="#alsa">ALSA</a></li>
<li><a href="#libffi">libffi</a></li>
</ul></li>
! <li><a href="#other-tooling-requirements">Other Tooling Requirements</a><ul>
<li><a href="#gnu-make">GNU Make</a></li>
<li><a href="#gnu-bash">GNU Bash</a></li>
- <li><a href="#autoconf">Autoconf</a></li>
</ul></li>
<li><a href="#running-configure">Running Configure</a><ul>
<li><a href="#common-configure-arguments">Common Configure Arguments</a></li>
<li><a href="#configure-control-variables">Configure Control Variables</a></li>
</ul></li>
--- 54,67 ----
<li><a href="#cups">CUPS</a></li>
<li><a href="#x11">X11</a></li>
<li><a href="#alsa">ALSA</a></li>
<li><a href="#libffi">libffi</a></li>
</ul></li>
! <li><a href="#build-tools-requirements">Build Tools Requirements</a><ul>
! <li><a href="#autoconf">Autoconf</a></li>
<li><a href="#gnu-make">GNU Make</a></li>
<li><a href="#gnu-bash">GNU Bash</a></li>
</ul></li>
<li><a href="#running-configure">Running Configure</a><ul>
<li><a href="#common-configure-arguments">Common Configure Arguments</a></li>
<li><a href="#configure-control-variables">Configure Control Variables</a></li>
</ul></li>
*** 114,127 ****
</nav>
<h2 id="tldr-instructions-for-the-impatient">TL;DR (Instructions for the Impatient)</h2>
<p>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.</p>
<ol type="1">
<li><p><a href="#getting-the-source-code">Get the complete source code</a>:<br />
! <code>hg clone http://hg.openjdk.java.net/jdk10/master</code></p></li>
<li><p><a href="#running-configure">Run configure</a>:<br />
<code>bash configure</code></p>
! <p>If <code>configure</code> fails due to missing dependencies (to either the <a href="#native-compiler-toolchain-requirements">toolchain</a>, <a href="#external-library-requirements">external libraries</a> or the <a href="#boot-jdk-requirements">boot JDK</a>), most of the time it prints a suggestion on how to resolve the situation on your platform. Follow the instructions, and try running <code>bash configure</code> again.</p></li>
<li><p><a href="#running-make">Run make</a>:<br />
<code>make images</code></p></li>
<li><p>Verify your newly built JDK:<br />
<code>./build/*/images/jdk/bin/java -version</code></p></li>
<li><p><a href="##running-tests">Run basic tests</a>:<br />
--- 114,127 ----
</nav>
<h2 id="tldr-instructions-for-the-impatient">TL;DR (Instructions for the Impatient)</h2>
<p>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.</p>
<ol type="1">
<li><p><a href="#getting-the-source-code">Get the complete source code</a>:<br />
! <code>hg clone http://hg.openjdk.java.net/jdk/jdk</code></p></li>
<li><p><a href="#running-configure">Run configure</a>:<br />
<code>bash configure</code></p>
! <p>If <code>configure</code> fails due to missing dependencies (to either the <a href="#native-compiler-toolchain-requirements">toolchain</a>, <a href="#build-tools-requirements">build tools</a>, <a href="#external-library-requirements">external libraries</a> or the <a href="#boot-jdk-requirements">boot JDK</a>), most of the time it prints a suggestion on how to resolve the situation on your platform. Follow the instructions, and try running <code>bash configure</code> again.</p></li>
<li><p><a href="#running-make">Run make</a>:<br />
<code>make images</code></p></li>
<li><p>Verify your newly built JDK:<br />
<code>./build/*/images/jdk/bin/java -version</code></p></li>
<li><p><a href="##running-tests">Run basic tests</a>:<br />
*** 199,214 ****
<p>A functioning <a href="http://www.cygwin.com/">Cygwin</a> environment is thus required for building OpenJDK on Windows. If you have a 64-bit OS, we strongly recommend using the 64-bit version of Cygwin.</p>
<p><strong>Note:</strong> 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 OpenJDK build process, and that can cause unexpected build problems.</p>
<p>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.</p>
<p>Apart from the basic Cygwin installation, the following packages must also be installed:</p>
<ul>
<li><code>make</code></li>
<li><code>zip</code></li>
<li><code>unzip</code></li>
</ul>
<p>Often, you can install these packages using the following command line:</p>
! <pre><code><path to Cygwin setup>/setup-x86_64 -q -P make -P unzip -P zip</code></pre>
<p>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 <a href="https://cygwin.com/faq/faq.html#faq.using.bloda">"BLODA" list</a> and the section on <a href="https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures">fork() failures</a>.</p>
<h3 id="solaris">Solaris</h3>
<p>See <code>make/devkit/solaris11.1-package-list.txt</code> 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.</p>
<p>Older versions of Solaris shipped a broken version of <code>objcopy</code>. 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.</p>
<h3 id="macos">macOS</h3>
--- 199,215 ----
<p>A functioning <a href="http://www.cygwin.com/">Cygwin</a> environment is thus required for building OpenJDK on Windows. If you have a 64-bit OS, we strongly recommend using the 64-bit version of Cygwin.</p>
<p><strong>Note:</strong> 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 OpenJDK build process, and that can cause unexpected build problems.</p>
<p>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.</p>
<p>Apart from the basic Cygwin installation, the following packages must also be installed:</p>
<ul>
+ <li><code>autoconf</code></li>
<li><code>make</code></li>
<li><code>zip</code></li>
<li><code>unzip</code></li>
</ul>
<p>Often, you can install these packages using the following command line:</p>
! <pre><code><path to Cygwin setup>/setup-x86_64 -q -P autoconf -P make -P unzip -P zip</code></pre>
<p>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 <a href="https://cygwin.com/faq/faq.html#faq.using.bloda">"BLODA" list</a> and the section on <a href="https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures">fork() failures</a>.</p>
<h3 id="solaris">Solaris</h3>
<p>See <code>make/devkit/solaris11.1-package-list.txt</code> 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.</p>
<p>Older versions of Solaris shipped a broken version of <code>objcopy</code>. 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.</p>
<h3 id="macos">macOS</h3>
*** 422,445 ****
<ul>
<li>To install on an apt-based Linux, try running <code>sudo apt-get install libffi-dev</code>.</li>
<li>To install on an rpm-based Linux, try running <code>sudo yum install libffi-devel</code>.</li>
</ul>
<p>Use <code>--with-libffi=<path></code> if <code>configure</code> does not properly locate your libffi files.</p>
! <h2 id="other-tooling-requirements">Other Tooling Requirements</h2>
<h3 id="gnu-make">GNU Make</h3>
<p>OpenJDK requires <a href="http://www.gnu.org/software/make">GNU Make</a>. No other flavors of make are supported.</p>
<p>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 <code>--with-output-sync</code>) and speed and stability improvements.</p>
<p>Note that <code>configure</code> locates and verifies a properly functioning version of <code>make</code> and stores the path to this <code>make</code> binary in the configuration. If you start a build using <code>make</code> on the command line, you will be using the version of make found first in your <code>PATH</code>, and not necessarily the one stored in the configuration. This initial make will be used as "bootstrap make", and in a second stage, the make located by <code>configure</code> will be called. Normally, this will present no issues, but if you have a very old <code>make</code>, or a non-GNU Make <code>make</code> in your path, this might cause issues.</p>
<p>If you want to override the default make found by <code>configure</code>, use the <code>MAKE</code> configure variable, e.g. <code>configure MAKE=/opt/gnu/make</code>.</p>
<p>On Solaris, it is common to call the GNU version of make by using <code>gmake</code>.</p>
<h3 id="gnu-bash">GNU Bash</h3>
<p>OpenJDK requires <a href="http://www.gnu.org/software/bash">GNU Bash</a>. No other shells are supported.</p>
<p>At least version 3.2 of GNU Bash must be used.</p>
- <h3 id="autoconf">Autoconf</h3>
- <p>If you want to modify the build system itself, you need to install <a href="http://www.gnu.org/software/autoconf">Autoconf</a>.</p>
- <p>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 <code>configure</code> shell script.</p>
- <p>See the section on <a href="#autoconf-details">Autoconf Details</a> for details on how OpenJDK uses autoconf. This is especially important if you plan to contribute changes to OpenJDK that modifies the build system.</p>
<h2 id="running-configure">Running Configure</h2>
<p>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.</p>
<p>The configuration is created by the <code>configure</code> script. The basic invocation of the <code>configure</code> script looks like this:</p>
<pre><code>bash configure [options]</code></pre>
<p>This will create an output directory containing the configuration and setup an area for the build result. This directory typically looks like <code>build/linux-x64-normal-server-release</code>, but the actual name depends on your specific configuration. (It can also be set directly, see <a href="#using-multiple-configurations">Using Multiple Configurations</a>). This directory is referred to as <code>$BUILD</code> in this documentation.</p>
--- 423,452 ----
<ul>
<li>To install on an apt-based Linux, try running <code>sudo apt-get install libffi-dev</code>.</li>
<li>To install on an rpm-based Linux, try running <code>sudo yum install libffi-devel</code>.</li>
</ul>
<p>Use <code>--with-libffi=<path></code> if <code>configure</code> does not properly locate your libffi files.</p>
! <h2 id="build-tools-requirements">Build Tools Requirements</h2>
! <h3 id="autoconf">Autoconf</h3>
! <p>OpenJDK requires <a href="http://www.gnu.org/software/autoconf">Autoconf</a> on all platforms. At least version 2.69 is required.</p>
! <ul>
! <li>To install on an apt-based Linux, try running <code>sudo apt-get install autoconf</code>.</li>
! <li>To install on an rpm-based Linux, try running <code>sudo yum install autoconf</code>.</li>
! <li>To install on macOS, try running <code>brew install autoconf</code>.</li>
! <li>To install on Windows, try running <code><path to Cygwin setup>/setup-x86_64 -q -P autoconf</code>.</li>
! </ul>
! <p>If <code>configure</code> has problems locating your installation of autoconf, you can specify it using the <code>AUTOCONF</code> environment variable, like this:</p>
! <pre><code>AUTOCONF=<path to autoconf> configure ...</code></pre>
<h3 id="gnu-make">GNU Make</h3>
<p>OpenJDK requires <a href="http://www.gnu.org/software/make">GNU Make</a>. No other flavors of make are supported.</p>
<p>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 <code>--with-output-sync</code>) and speed and stability improvements.</p>
<p>Note that <code>configure</code> locates and verifies a properly functioning version of <code>make</code> and stores the path to this <code>make</code> binary in the configuration. If you start a build using <code>make</code> on the command line, you will be using the version of make found first in your <code>PATH</code>, and not necessarily the one stored in the configuration. This initial make will be used as "bootstrap make", and in a second stage, the make located by <code>configure</code> will be called. Normally, this will present no issues, but if you have a very old <code>make</code>, or a non-GNU Make <code>make</code> in your path, this might cause issues.</p>
<p>If you want to override the default make found by <code>configure</code>, use the <code>MAKE</code> configure variable, e.g. <code>configure MAKE=/opt/gnu/make</code>.</p>
<p>On Solaris, it is common to call the GNU version of make by using <code>gmake</code>.</p>
<h3 id="gnu-bash">GNU Bash</h3>
<p>OpenJDK requires <a href="http://www.gnu.org/software/bash">GNU Bash</a>. No other shells are supported.</p>
<p>At least version 3.2 of GNU Bash must be used.</p>
<h2 id="running-configure">Running Configure</h2>
<p>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.</p>
<p>The configuration is created by the <code>configure</code> script. The basic invocation of the <code>configure</code> script looks like this:</p>
<pre><code>bash configure [options]</code></pre>
<p>This will create an output directory containing the configuration and setup an area for the build result. This directory typically looks like <code>build/linux-x64-normal-server-release</code>, but the actual name depends on your specific configuration. (It can also be set directly, see <a href="#using-multiple-configurations">Using Multiple Configurations</a>). This directory is referred to as <code>$BUILD</code> in this documentation.</p>
*** 749,759 ****
<pre><code>fatal error - couldn't allocate heap
cannot create ... Permission denied
spawn failed</code></pre>
<p>This can be a sign of a Cygwin problem. See the information about solving problems in the <a href="#cygwin">Cygwin</a> section. Rebooting the computer might help temporarily.</p>
<h3 id="getting-help">Getting Help</h3>
! <p>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 <a href="mailto:build-dev@openjdk.java.net">build-dev@openjdk.java.net</a>. Please include the relevant parts of the configure and/or build log.</p>
<p>If you need general help or advice about developing for OpenJDK, you can also contact the Adoption Group. See the section on <a href="#contributing-to-openjdk">Contributing to OpenJDK</a> for more information.</p>
<h2 id="hints-and-suggestions-for-advanced-users">Hints and Suggestions for Advanced Users</h2>
<h3 id="setting-up-a-forest-for-pushing-changes-defpath">Setting Up a Forest for Pushing Changes (defpath)</h3>
<p>To help you prepare a proper push path for a Mercurial repository, there exists a useful tool known as <a href="http://openjdk.java.net/projects/code-tools/defpath">defpath</a>. It will help you setup a proper push path for pushing changes to OpenJDK.</p>
<p>Install the extension by cloning <code>http://hg.openjdk.java.net/code-tools/defpath</code> and updating your <code>.hgrc</code> file. Here's one way to do this:</p>
--- 756,771 ----
<pre><code>fatal error - couldn't allocate heap
cannot create ... Permission denied
spawn failed</code></pre>
<p>This can be a sign of a Cygwin problem. See the information about solving problems in the <a href="#cygwin">Cygwin</a> section. Rebooting the computer might help temporarily.</p>
<h3 id="getting-help">Getting Help</h3>
! <p>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 <script type="text/javascript">
! <!--
! h='openjdk.java.net';a='@';n='build-dev';e=n+a+h;
! document.write('<a h'+'ref'+'="ma'+'ilto'+':'+e+'" clas'+'s="em' + 'ail">'+e+'<\/'+'a'+'>');
! // -->
! </script><noscript>build-dev at openjdk dot java dot net</noscript>. Please include the relevant parts of the configure and/or build log.</p>
<p>If you need general help or advice about developing for OpenJDK, you can also contact the Adoption Group. See the section on <a href="#contributing-to-openjdk">Contributing to OpenJDK</a> for more information.</p>
<h2 id="hints-and-suggestions-for-advanced-users">Hints and Suggestions for Advanced Users</h2>
<h3 id="setting-up-a-forest-for-pushing-changes-defpath">Setting Up a Forest for Pushing Changes (defpath)</h3>
<p>To help you prepare a proper push path for a Mercurial repository, there exists a useful tool known as <a href="http://openjdk.java.net/projects/code-tools/defpath">defpath</a>. It will help you setup a proper push path for pushing changes to OpenJDK.</p>
<p>Install the extension by cloning <code>http://hg.openjdk.java.net/code-tools/defpath</code> and updating your <code>.hgrc</code> file. Here's one way to do this:</p>
*** 869,887 ****
<li><p><code>zipped</code> is like <code>external</code>, but the .debuginfo file will also be zipped into a <code>.diz</code> file.</p></li>
</ul>
<p>When building for distribution, <code>zipped</code> is a good solution. Binaries built with <code>internal</code> is suitable for use by developers, since they facilitate debugging, but should be stripped before distributed to end users.</p>
<h3 id="autoconf-details">Autoconf Details</h3>
<p>The <code>configure</code> script is based on the autoconf framework, but in some details deviate from a normal autoconf <code>configure</code> script.</p>
! <p>The <code>configure</code> script in the top level directory of OpenJDK is just a thin wrapper that calls <code>make/autoconf/configure</code>. This in turn provides functionality that is not easily expressed in the normal Autoconf framework, and then calls into the core of the <code>configure</code> script, which is the <code>make/autoconf/generated-configure.sh</code> file.</p>
! <p>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.</p>
! <p>The build system will detect if the Autoconf source files have changed, and will trigger a regeneration of <code>make/autoconf/generated-configure.sh</code> if needed. You can also manually request such an update by <code>bash make/autoconf/autogen.sh</code>.</p>
! <p>If you make changes to the build system that requires a re-generation, note the following:</p>
! <ul>
! <li><p>You must use <em>exactly</em> 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.</p></li>
! <li><p>You do not need to include the generated file in reviews.</p></li>
! <li><p>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.</p></li>
! </ul>
<h3 id="developing-the-build-system-itself">Developing the Build System Itself</h3>
<p>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.</p>
<p>While technically using <code>make</code>, 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 <code>make/common</code>. For instance, to compile all classes in the <code>jdk.internal.foo</code> package in the <code>jdk.foo</code> module, a call like this would be made:</p>
<pre><code>$(eval $(call SetupJavaCompilation, BUILD_FOO_CLASSES, \
SETUP := GENERATE_OLDBYTECODE, \
--- 881,893 ----
<li><p><code>zipped</code> is like <code>external</code>, but the .debuginfo file will also be zipped into a <code>.diz</code> file.</p></li>
</ul>
<p>When building for distribution, <code>zipped</code> is a good solution. Binaries built with <code>internal</code> is suitable for use by developers, since they facilitate debugging, but should be stripped before distributed to end users.</p>
<h3 id="autoconf-details">Autoconf Details</h3>
<p>The <code>configure</code> script is based on the autoconf framework, but in some details deviate from a normal autoconf <code>configure</code> script.</p>
! <p>The <code>configure</code> script in the top level directory of OpenJDK is just a thin wrapper that calls <code>make/autoconf/configure</code>. This in turn will run <code>autoconf</code> to create the runnable (generated) configure script, as <code>.build/generated-configure.sh</code>. Apart from being responsible for the generation of the runnable script, the <code>configure</code> script also provides functionality that is not easily expressed in the normal Autoconf framework. As part of this functionality, the generated script is called.</p>
! <p>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 <code>bash configure autogen</code>.</p>
! <p>In previous versions of the OpenJDK, the generated script was checked in at <code>make/autoconf/generated-configure.sh</code>. This is no longer the case.</p>
<h3 id="developing-the-build-system-itself">Developing the Build System Itself</h3>
<p>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.</p>
<p>While technically using <code>make</code>, 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 <code>make/common</code>. For instance, to compile all classes in the <code>jdk.internal.foo</code> package in the <code>jdk.foo</code> module, a call like this would be made:</p>
<pre><code>$(eval $(call SetupJavaCompilation, BUILD_FOO_CLASSES, \
SETUP := GENERATE_OLDBYTECODE, \
*** 895,905 ****
<p>To compare the output of two different builds and see if, and how, they differ, run <code>$BUILD1/compare.sh -o $BUILD2</code>, where <code>$BUILD1</code> and <code>$BUILD2</code> are the two builds you want to compare.</p>
<p>To automatically build two consecutive versions and compare them, use <code>COMPARE_BUILD</code>. The value of <code>COMPARE_BUILD</code> is a set of variable=value assignments, like this:</p>
<pre><code>make COMPARE_BUILD=CONF=--enable-new-hotspot-feature:MAKE=hotspot</code></pre>
<p>See <code>make/InitSupport.gmk</code> for details on how to use <code>COMPARE_BUILD</code>.</p>
<p>To analyze build performance, run with <code>LOG=trace</code> and check <code>$BUILD/build-trace-time.log</code>. Use <code>JOBS=1</code> to avoid parallelism.</p>
! <p>Please check that you adhere to the <a href="http://openjdk.java.net/groups/build/doc/code-conventions.html">Code Conventions for the Build System</a> before submitting patches. Also see the section in <a href="#autoconf-details">Autoconf Details</a> about the generated configure script.</p>
<h2 id="contributing-to-openjdk">Contributing to OpenJDK</h2>
<p>So, now you've build your OpenJDK, and made your first patch, and want to contribute it back to the OpenJDK community.</p>
<p>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.</p>
<p>The official place to start is the <a href="http://openjdk.java.net/contribute/">'How to contribute' page</a>. There is also an official (but somewhat outdated and skimpy on details) <a href="http://openjdk.java.net/guide/">Developer's Guide</a>.</p>
<p>If this seems overwhelming to you, the Adoption Group is there to help you! A good place to start is their <a href="https://wiki.openjdk.java.net/display/Adoption/New+Contributor">'New Contributor' page</a>, or start reading the comprehensive <a href="https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting-started-kit/en/">Getting Started Kit</a>. The Adoption Group will also happily answer any questions you have about contributing. Contact them by <a href="http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss">mail</a> or <a href="http://openjdk.java.net/irc/">IRC</a>.</p>
--- 901,911 ----
<p>To compare the output of two different builds and see if, and how, they differ, run <code>$BUILD1/compare.sh -o $BUILD2</code>, where <code>$BUILD1</code> and <code>$BUILD2</code> are the two builds you want to compare.</p>
<p>To automatically build two consecutive versions and compare them, use <code>COMPARE_BUILD</code>. The value of <code>COMPARE_BUILD</code> is a set of variable=value assignments, like this:</p>
<pre><code>make COMPARE_BUILD=CONF=--enable-new-hotspot-feature:MAKE=hotspot</code></pre>
<p>See <code>make/InitSupport.gmk</code> for details on how to use <code>COMPARE_BUILD</code>.</p>
<p>To analyze build performance, run with <code>LOG=trace</code> and check <code>$BUILD/build-trace-time.log</code>. Use <code>JOBS=1</code> to avoid parallelism.</p>
! <p>Please check that you adhere to the <a href="http://openjdk.java.net/groups/build/doc/code-conventions.html">Code Conventions for the Build System</a> before submitting patches.</p>
<h2 id="contributing-to-openjdk">Contributing to OpenJDK</h2>
<p>So, now you've build your OpenJDK, and made your first patch, and want to contribute it back to the OpenJDK community.</p>
<p>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.</p>
<p>The official place to start is the <a href="http://openjdk.java.net/contribute/">'How to contribute' page</a>. There is also an official (but somewhat outdated and skimpy on details) <a href="http://openjdk.java.net/guide/">Developer's Guide</a>.</p>
<p>If this seems overwhelming to you, the Adoption Group is there to help you! A good place to start is their <a href="https://wiki.openjdk.java.net/display/Adoption/New+Contributor">'New Contributor' page</a>, or start reading the comprehensive <a href="https://adoptopenjdk.gitbooks.io/adoptopenjdk-getting-started-kit/en/">Getting Started Kit</a>. The Adoption Group will also happily answer any questions you have about contributing. Contact them by <a href="http://mail.openjdk.java.net/mailman/listinfo/adoption-discuss">mail</a> or <a href="http://openjdk.java.net/irc/">IRC</a>.</p>
< prev index next >