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.
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.
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 and 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.
FreeType2 from The FreeType Project 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.
+FreeType2 from The FreeType Project 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.
sudo apt-get install libfreetype6-dev.sudo yum install freetype-devel.To build the JDK, 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 the JDK is built.
The configuration is created by the configure script. The basic invocation of the configure script looks like this:
bash configure [options]This will create an output directory containing the configuration and setup an area for the build result. This directory typically looks like build/linux-x64-normal-server-release, but the actual name depends on your specific configuration. (It can also be set directly, see Using Multiple Configurations). This directory is referred to as $BUILD in this documentation.
This will create an output directory containing the configuration and setup an area for the build result. This directory typically looks like build/linux-x64-server-release, but the actual name depends on your specific configuration. (It can also be set directly, see Using Multiple Configurations). This directory is referred to as $BUILD in this documentation.
configure will try to figure out what system you are running on and where all necessary build components are. If you have all prerequisites for building installed, it should find everything. If it fails to detect any component automatically, it will exit and inform you about the problem.
Some command line examples:
It is highly recommended to use the latest NSS version when running PKCS11 tests. Improper NSS version may lead to unexpected failures which are hard to diagnose. For example, sun/security/pkcs11/Secmod/AddTrustedCert.java may fail on Ubuntu 18.04 with the default NSS version in the system. To run these tests correctly, the system property test.nss.lib.paths is required on Ubuntu 18.04 to specify the alternative NSS lib directories. For example:
$ make test TEST="jtreg:sun/security/pkcs11/Secmod/AddTrustedCert.java" JTREG="JAVA_OPTIONS=-Dtest.nss.lib.paths=/path/to/your/latest/NSS-libs"For more notes about the PKCS11 tests, please refer to test/jdk/sun/security/pkcs11/README.
+Some Client UI tests use key sequences which may be reserved by the operating system. Usually that causes the test failure. So it is highly recommended to disable system key shortcuts prior testing. The steps to access and disable system key shortcuts for various platforms are provided below.
+Choose Apple menu; System Preferences, click Keyboard, then click Shortcuts; select or deselect desired shortcut.
+For example, test/jdk/javax/swing/TooltipManager/JMenuItemToolTipKeyBindingsTest/JMenuItemToolTipKeyBindingsTest.java fails on MacOS because it uses CTRL + F1 key sequence to show or hide tooltip message but the key combination is reserved by the operating system. To run the test correctly the default global key shortcut should be disabled using the steps described above, and then deselect "Turn keyboard access on or off" option which is responsible for CTRL + F1 combination.
Open the Activities overview and start typing Settings; Choose Settings, click Devices, then click Keyboard; set or override desired shortcut.
+Type gpedit in the Search and then click Edit group policy; navigate to User Configuration -> Administrative Templates -> Windows Components -> File Explorer; in the right-side pane look for "Turn off Windows key hotkeys" and double click on it; enable or disable hotkeys.
Note: restart is required to make the settings take effect.