This README file contains build instructions for the +OpenJDK. Building the source code for the OpenJDK +requires a certain degree of technical expertise.
+ +Some Headlines:
+ +configure && make" style buildvsvars*.bat and vcvars*.bat files are run
+automaticallyThe OpenJDK sources are maintained with the revision control system +Mercurial. If you are new to +Mercurial, please see the Beginner Guides or refer to the Mercurial Book. +The first few chapters of the book provide an excellent overview of Mercurial, +what it is and how it works.
+ +For using Mercurial with the OpenJDK refer to the Developer Guide: Installing +and Configuring Mercurial section for more information.
+ + + +To get the entire set of OpenJDK Mercurial repositories use the script
+get_source.sh located in the root repository:
hg clone http://hg.openjdk.java.net/jdk9/jdk9 YourOpenJDK
+ cd YourOpenJDK
+ bash ./get_source.sh
+Once you have all the repositories, keep in mind that each repository is its
+own independent repository. You can also re-run ./get_source.sh anytime to
+pull over all the latest changesets in all the repositories. This set of
+nested repositories has been given the term "forest" and there are various
+ways to apply the same hg command to each of the repositories. For
+example, the script make/scripts/hgforest.sh can be used to repeat the
+same hg command on every repository, e.g.
cd YourOpenJDK
+ bash ./make/scripts/hgforest.sh status
+The set of repositories and what they contain:
+ +There are some very basic guidelines:
+ +build/ directory..hgignore file in each repository must exist and should include
+^build/, ^dist/ and optionally any nbproject/private directories. It
+should NEVER include anything in the src/ or test/ or any managed
+directory area of a repository.javah output). There are some exceptions to this rule, in
+particular with some of the generated configure scripts.The very first step in building the OpenJDK is making sure the system itself +has everything it needs to do OpenJDK builds. Once a system is setup, it +generally doesn't need to be done again.
+ +Building the OpenJDK is now done with running a configure script which will
+try and find and verify you have everything you need, followed by running
+make, e.g.
|
-
- |
-
- OpenJDK Build README- |
-
- This README file contains build instructions for the - OpenJDK. - Building the source code for the - OpenJDK - requires - a certain degree of technical expertise. - - -- - -!!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!!
-- Some Headlines: ---
-- - The build is now a "
-configure && make" style build -- - Any GNU make 3.81 or newer should work, except on - Windows where 4.0 or newer is recommended. -
-- - The build should scale, i.e. more processors should - cause the build to be done in less wall-clock time -
-- - Nested or recursive make invocations have been significantly - reduced, as has the total fork/exec or spawning - of sub processes during the build -
-- - Windows MKS usage is no longer supported -
-- - Windows Visual Studio
-vsvars*.batand -vcvars*.batfiles are run automatically -- - Ant is no longer used when building the OpenJDK -
-- - Use of ALT_* environment variables for configuring the - build is no longer supported -
-
-- - --
-- Introduction
- -- Use of Mercurial - -
- -- Building - -
-- Testing
-
- -
- The OpenJDK sources are maintained with the revision control system - Mercurial. - If you are new to Mercurial, please see the - - Beginner Guides - or refer to the - Mercurial Book. - The first few chapters of the book provide an excellent overview of - Mercurial, what it is and how it works. -- - -
- For using Mercurial with the OpenJDK refer to the - - Developer Guide: Installing and Configuring Mercurial - section for more information. - -Getting the Source
-- To get the entire set of OpenJDK Mercurial repositories - use the script- -get_source.shlocated in the - root repository: --- Once you have all the repositories, keep in mind that each - repository is its own independent repository. - You can also re-run- hg clone http://hg.openjdk.java.net/jdk9/jdk9 - YourOpenJDK --
- cd YourOpenJDK -
- bash ./get_source.sh -./get_source.shanytime to - pull over all the latest changesets in all the repositories. - This set of nested repositories has been given the term - "forest" and there are various ways to apply the same -hgcommand to each of the repositories. - For example, the scriptmake/scripts/hgforest.sh- can be used to repeat the samehg- command on every repository, e.g. ---- cd YourOpenJDK --
- bash ./make/scripts/hgforest.sh status -Repositories
--- -The set of repositories and what they contain:
-- -
-- - - -Repository -Contains -- -- . (root) - -- common configure and makefile logic - -- -- hotspot - -- source code and make files for building - the OpenJDK Hotspot Virtual Machine - -- -- langtools - -- source code for the OpenJDK javac and language tools - -- -- jdk - -- source code and make files for building - the OpenJDK runtime libraries and misc files - -- -- jaxp - -- source code for the OpenJDK JAXP functionality - -- -- jaxws - -- source code for the OpenJDK JAX-WS functionality - -- -- corba - -- source code for the OpenJDK Corba functionality - -- - -- nashorn - -- source code for the OpenJDK JavaScript implementation - -Repository Source Guidelines
-- There are some very basic guidelines: -- --
-- - Use of whitespace in source files - (.java, .c, .h, .cpp, and .hpp files) - is restricted. - No TABs, no trailing whitespace on lines, and files - should not terminate in more than one blank line. -
-- - Files with execute permissions should not be added - to the source repositories. -
-- - All generated files need to be kept isolated from - the files - maintained or managed by the source control system. - The standard area for generated files is the top level -
-build/directory. -- - The default build process should be to build the product - and nothing else, in one form, e.g. a product (optimized), - debug (non-optimized, -g plus assert logic), or - fastdebug (optimized, -g plus assert logic). -
-- - The .hgignore file in each repository - must exist and should - include ^build/, ^dist/ and - optionally any - nbproject/private directories. - It should NEVER include - anything in the - src/ or test/ - or any managed directory area of a repository. -
-- - Directory names and file names should never contain - blanks or - non-printing characters. -
-- - Generated source or binary files should NEVER be added to - the repository (that includes javah output). - There are some exceptions to this rule, in particular - with some of the generated configure scripts. -
-- - Files not needed for typical building - or testing of the repository - should not be added to the repository. -
-
- The very first step in building the OpenJDK is making sure the - system itself has everything it needs to do OpenJDK builds. - Once a system is setup, it generally doesn't need to be done again. -- - -
- Building the OpenJDK is now done with running a -configure- script which will try and find and verify you have everything - you need, followed by running -make, e.g. -- -- Where possible the- bash ./configure- -
- make all -configurescript will attempt to located the - various components in the default locations or via component - specific variable settings. - When the normal defaults fail or components cannot be found, - additionalconfigureoptions may be necessary to helpconfigure- find the necessary tools for the build, or you may need to - re-visit the setup of your system due to missing software - packages. -
- NOTE: Theconfigurescript - file does not have - execute permissions and will need to be explicitly run with -bash, - see the source guidelines. - - -
-System Setup
-- Before even attempting to use a system to build the OpenJDK - there are some very basic system setups needed. - For all systems: -- - --
- And for specific systems: -- - Be sure the GNU make utility is version 3.81 (4.0 on - windows) or newer, e.g. run "
-make -version" -- - Install a - Bootstrap JDK. - All OpenJDK builds require access to a previously released - JDK called the bootstrap JDK or boot JDK. - The general rule is that the bootstrap JDK - must be an instance of the previous major - release of the JDK. In addition, there may be - a requirement to use a release at or beyond a - particular update level. -
-
- - Building JDK 9 requires JDK 8. JDK 9 - developers should not use JDK 9 as the boot - JDK, to ensure that JDK 9 dependencies are - not introduced into the parts of the system - that are built with JDK 8. - -
- The JDK 8 binaries can be downloaded from Oracle's - JDK 8 download site. - For build performance reasons it - is very important that this bootstrap JDK be made available - on the local disk of the machine doing the build. - You should add itsbindirectory - to thePATHenvironment variable. - Ifconfigurehas any issues finding this JDK, you may - need to use theconfigureoption ---with-boot-jdk. -- - Ensure that GNU make, the Bootstrap JDK, - and the compilers are all - in your PATH environment variable -
-- -
- -- - - -Linux -Solaris -Windows -Mac OS X -- - -- Install all the software development - packages needed including - alsa, - freetype, - cups, and - xrender. - -
- See - specific system packages. -- Install all the software development - packages needed including - Studio Compilers, - freetype, - cups, and - xrender. - -
- See - specific system packages. -- --
-- - Install one of - CYGWIN or - MinGW/MSYS -
-- - Install - Visual Studio 2013 -
-- Install - XCode 4.5.2 - and also install the "Command line tools" found under the - preferences pane "Downloads" - -Linux
-- With Linux, try and favor the system packages over - building your own - or getting packages from other areas. - Most Linux builds should be possible with the system's - available packages. -- -
- Note that some Linux systems have a habit of pre-populating - your environment variables for you, for exampleJAVA_HOME- might get pre-defined for you to refer to the JDK installed on - your Linux system. - You will need to unsetJAVA_HOME. - It's a good idea to runenvand verify the - environment variables you are getting from the default system - settings make sense for building the OpenJDK. - -Solaris
--- -Studio Compilers
-- At a minimum, the - - Studio 12 Update 1 Compilers - (containing version 5.10 of the C and C++ compilers) is required, - including specific patches. -- -- The Solaris SPARC patch list is: -
-
-- - 118683-05: SunOS 5.10: Patch for profiling libraries and assembler -
-- - 119963-21: SunOS 5.10: Shared library patch for C++ -
-- - 120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch -
-- - 128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler -
-- - 141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 -
-- - 141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler -
-- - 142371-01: Sun Studio 12.1 Update 1: Patch for dbx -
-- - 143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling -
-- - 143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C C++ F77 F95 -
-- - 142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools -
-- The Solaris X86 patch list is: -
-
-- - 119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler -
-- - 119964-21: SunOS 5.10_x86: Shared library patch for C++_x86 -
-- - 120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch -
-- - 141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 backend -
-- - 128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler -
-- - 142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler -
-- - 142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools -
-- Place the
bindirectory inPATH. -- The Oracle Solaris Studio Express compilers at: - - Oracle Solaris Studio Express Download site - are also an option, although these compilers have not - been extensively used yet. -
Windows
-- -- -Windows Unix Toolkit
-- Building on Windows requires a Unix-like environment, notably a - Unix-like shell. - There are several such environments available of which - Cygwin and - MinGW/MSYS are - currently supported for - the OpenJDK build. One of the differences of these - systems from standard Windows tools is the way - they handle Windows path names, particularly path names which contain - spaces, backslashes as path separators and possibly drive letters. - Depending - on the use case and the specifics of each environment these path - problems can - be solved by a combination of quoting whole paths, translating - backslashes to - forward slashes, escaping backslashes with additional backslashes and - translating the path names to their - - "8.3" version. - -- -CYGWIN
-- CYGWIN is an open source, Linux-like environment which tries to emulate - a complete POSIX layer on Windows. It tries to be smart about path names - and can usually handle all kinds of paths if they are correctly quoted - or escaped although internally it maps drive letters- -<drive>:- to a virtual directory/cygdrive/<drive>. -- You can always use the
-cygpathutility to map pathnames with spaces - or the backslash character into theC:/style of pathname - (called 'mixed'), e.g.cygpath -s -m "path". -- Note that the use of CYGWIN creates a unique problem with regards to - setting
-PATH. Normally on Windows - thePATHvariable contains directories - separated with the ";" character (Solaris and Linux use ":"). - With CYGWIN, it uses ":", but that means that paths like "C:/path" - cannot be placed in the CYGWIN version ofPATHand - instead CYGWIN uses something like/cygdrive/c/path- which CYGWIN understands, but only CYGWIN understands. -- The OpenJDK build requires CYGWIN version 1.7.16 or newer. - Information about CYGWIN can - be obtained from the CYGWIN website at - www.cygwin.com. -
-- By default CYGWIN doesn't install all the tools required for building - the OpenJDK. - Along with the default installation, you need to install - the following tools. -
-- Note that the CYGWIN software can conflict with other non-CYGWIN - software on your Windows system. - CYGWIN provides a - FAQ for - known issues and problems, of particular interest is the - section on - - BLODA (applications that interfere with CYGWIN). -- -
-- - - -Binary Name -Category -Package -Description -- -ar.exe -Devel -binutils -- The GNU assembler, linker and binary utilities - -- -make.exe -Devel -make -- The GNU version of the 'make' utility built for CYGWIN - -- -m4.exe -Interpreters -m4 -- GNU implementation of the traditional Unix macro - processor - -- -cpio.exe -Utils -cpio -- A program to manage archives of files - -- -gawk.exe -Utils -awk -- Pattern-directed scanning and processing language - -- -file.exe -Utils -file -- Determines file type using 'magic' numbers - -- -zip.exe -Archive -zip -- Package and compress (archive) files - -- -unzip.exe -Archive -unzip -- Extract compressed files in a ZIP archive - -- - -free.exe -System -procps -- Display amount of free and used memory in the system - -MinGW/MSYS
-- MinGW ("Minimalist GNU for Windows") is a collection of free Windows - specific header files and import libraries combined with GNU toolsets that - allow one to produce native Windows programs that do not rely on any - 3rd-party C runtime DLLs. MSYS is a supplement to MinGW which allows building - applications and programs which rely on traditional UNIX tools to - be present. Among others this includes tools like- -bash- andmake. - See MinGW/MSYS - for more information. -- Like Cygwin, MinGW/MSYS can handle different types of path formats. They - are internally converted to paths with forward slashes and drive letters -
-<drive>:replaced by a virtual - directory/<drive>. Additionally, MSYS automatically - detects binaries compiled for the MSYS environment and feeds them with the - internal, Unix-style path names. If native Windows applications are called - from within MSYS programs their path arguments are automatically converted - back to Windows style path names with drive letters and backslashes as - path separators. This may cause problems for Windows applications which - use forward slashes as parameter separator (e.g.cl /nologo /I) - because MSYS may wrongly - replace such parameters by drive letters. -- In addition to the tools which will be installed - by default, you have - to manually install the -
msys-zipand -msys-unzippackages. - This can be easily done with the MinGW command line installer: ---mingw-get.exe install msys-zip-
-mingw-get.exe install msys-unzip-Visual Studio 2013 Compilers
--- - -- The 32-bit and 64-bit OpenJDK Windows build requires - Microsoft Visual Studio C++ 2013 (VS2013) Professional - Edition or Express compiler. - The compiler and other tools are expected to reside - in the location defined by the variable -
-VS120COMNTOOLSwhich - is set by the Microsoft Visual Studio installer. -- Only the C++ part of VS2013 is needed. - Try to let the installation go to the default - install directory. - Always reboot your system after installing VS2013. - The system environment variable VS120COMNTOOLS - should be - set in your environment. -
-- Make sure that TMP and TEMP are also set - in the environment - and refer to Windows paths that exist, - like
-C:\temp, - not/tmp, not/cygdrive/c/temp, - and notC:/temp. -C:\tempis just an example, - it is assumed that this area is - private to the user, so by default - after installs you should - see a unique user path in these variables. -Mac OS X
-- Make sure you get the right XCode version. -- -
-Configure
-- The basic invocation of the- - -configurescript - looks like: --- This will create an output directory containing the - "configuration" and setup an area for the build result. - This directory typically looks like: -bash ./configure [options]---build/linux-x64-normal-server-release-configurewill 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. - When this happens, read more below in - theconfigureoptions. -- Some examples: -
-- -
- - -- - - -Description -Configure Command Line -- -Windows 32bit build with freetype specified -- -bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32-- - -Debug 64bit Build -- -bash ./configure --enable-debug --with-target-bits=64-Configure Options
-- Complete details on all the OpenJDK- -configureoptions can - be seen with: --- Usebash ./configure --help=short--helpto see all theconfigureoptions - available. - - You can generate any number of different configurations, - e.g. debug, release, 32, 64, etc. - - Some of the more commonly usedconfigureoptions are: - -- -
-- - - -OpenJDK Configure Option -Description -- -- --enable-debug- set the debug level to fastdebug (this is a shorthand for - ---with-debug-level=fastdebug) -- -- --with-alsa=path- select the location of the - Advanced Linux Sound Architecture (ALSA) - -
- Version 0.9.1 or newer of the ALSA files are - required for building the OpenJDK on Linux. - These Linux files are usually available from an "alsa" - of "libasound" - development package, - and it's highly recommended that you try and use - the package provided by the particular version of Linux that - you are using. -- -- --with-boot-jdk=path- select the Bootstrap JDK - -- -- --with-boot-jdk-jvmargs="args"- provide the JVM options to be used to run the - Bootstrap JDK - -- -- --with-cacerts=path- select the path to the cacerts file. - -
- See - http://en.wikipedia.org/wiki/Certificate_Authority - for a better understanding of the Certificate Authority (CA). - A certificates file named "cacerts" - represents a system-wide keystore with CA certificates. - In JDK and JRE - binary bundles, the "cacerts" file contains root CA certificates from - several public CAs (e.g., VeriSign, Thawte, and Baltimore). - The source contain a cacerts file - without CA root certificates. - Formal JDK builders will need to secure - permission from each public CA and include the certificates into their - own custom cacerts file. - Failure to provide a populated cacerts file - will result in verification errors of a certificate chain during runtime. - By default an empty cacerts file is provided and that should be - fine for most JDK developers. -- -- --with-cups=path- select the CUPS install location - -
- The - Common UNIX Printing System (CUPS) Headers - are required for building the - OpenJDK on Solaris and Linux. - The Solaris header files can be obtained by installing - the package SFWcups from the Solaris Software - Companion CD/DVD, these often will be installed into the - directory/opt/sfw/cups. -
- The CUPS header files can always be downloaded from - www.cups.org. -- -- --with-cups-include=path- select the CUPS include directory location - -- -- --with-debug-level=level- select the debug information level of release, - fastdebug, or slowdebug - -- -- --with-dev-kit=path- select location of the compiler install or - developer install location - -- -- --with-freetype=path- select the freetype files to use. - -
- Expecting the - freetype libraries under -lib/and the - headers underinclude/. -
- Version 2.3 or newer of FreeType is required. - On Unix systems required files can be available as part of your - distribution (while you still may need to upgrade them). - Note that you need development version of package that - includes both the FreeType library and header files. -
- You can always download latest FreeType version from the - FreeType website. -
- Building the freetype 2 libraries from scratch is also possible, - however on Windows refer to the - - Windows FreeType DLL build instructions. -
- Note that by default FreeType is built with byte code hinting - support disabled due to licensing restrictions. - In this case, text appearance and metrics are expected to - differ from Sun's official JDK build. - See - - the SourceForge FreeType2 Home Page - - for more information. -- -- --with-import-hotspot=path- select the location to find hotspot - binaries from a previous build to avoid building - hotspot - -- -- --with-target-bits=arg- select 32 or 64 bit build - -- -- --with-jvm-variants=variants- select the JVM variants to build from, comma - separated list that can include: - server, client, kernel, zero and zeroshark - -- -- --with-memory-size=size- select the RAM size that GNU make will think - this system has - -- -- --with-msvcr-dll=path- select the -msvcr100.dll- file to include in the - Windows builds (C/C++ runtime library for - Visual Studio). -
- This is usually picked up automatically - from the redist - directories of Visual Studio 2013. -- -- --with-num-cores=cores- select the number of cores to use (processor - count or CPU count) - -- - -- --with-x=path- select the location of the X11 and xrender files. - -
- The - XRender Extension Headers - are required for building the - OpenJDK on Solaris and Linux. -
- The Linux header files are usually available from a "Xrender" - development package, it's recommended that you try and use - the package provided by the particular distribution of Linux that - you are using. -
- The Solaris XRender header files is - included with the other X11 header files - in the package SFWxwinc - on new enough versions of - Solaris and will be installed in -/usr/X11/include/X11/extensions/Xrender.hor -/usr/openwin/share/include/X11/extensions/Xrender.h-
-Make
-- The basic invocation of the-makeutility - looks like: --- This will start the build to the output directory containing the - "configuration" that was created by themake all-configure- script. Runmake helpfor more information on - the available targets. -
- There are some of the make targets that - are of general interest: -- -
-- - - -Make Target -Description -- -empty -build everything but no images -- -- allbuild everything including images -- -- all-confbuild all configurations -- -- imagescreate complete j2sdk and j2re images -- -- installinstall the generated images locally, - typically in -/usr/local- -- cleanremove all files generated by make, - but not those generated by -configure- -- dist-cleanremove all files generated by both - and -configure(basically killing the configuration)- - -- helpgive some help on using -make, - including some interesting make targets
- When the build is completed, you should see the generated - binaries and associated files in the- - - - - - - - - - - - -j2sdk-image- directory in the output directory. - In particular, the -build/*/images/j2sdk-image/bin- directory should contain executables for the - OpenJDK tools and utilities for that configuration. - The testing tooljtregwill be needed - and can be found at: - - the jtreg site. - The provided regression tests in the repositories - can be run with the command: ---cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all-
- -- - -FAQ
-- -- -- Q: The
- -generated-configure.shfile looks horrible! - How are you going to edit it? -
- A: Thegenerated-configure.shfile is generated (think - "compiled") by the autoconf tools. The source code is - inconfigure.acand various .m4 files in common/autoconf, - which are much more readable. -- Q: - Why is the
- -generated-configure.shfile checked in, - if it is generated? -
- A: - If it was not generated, every user would need to have the autoconf - tools installed, and re-generate theconfigurefile - as the first step. - Our goal is to minimize the work needed to be done by the user - to start building OpenJDK, and to minimize - the number of external dependencies required. -- Q: - Do you require a specific version of autoconf for regenerating -
- -generated-configure.sh? -
- A: - Yes, version 2.69 is required and should be easy - enough to aquire on all supported operating - systems. The reason for this is to avoid - large spurious changes ingenerated-configure.sh. -- Q: - How do you regenerate
- -generated-configure.sh- after making changes to the input files? -
- A: - Regneratinggenerated-configure.sh- should always be done using the - scriptcommon/autoconf/autogen.shto - ensure that the correct files get updated. This - script should also be run after mercurial tries to - mergegenerated-configure.shas a - merge of the generated file is not guaranteed to - be correct. -- Q: - What are the files in
- -common/makefiles/support/*for? - They look like gibberish. -
- A: - They are a somewhat ugly hack to compensate for command line length - limitations on certain platforms (Windows, Solaris). - Due to a combination of limitations in make and the shell, - command lines containing too many files will not work properly. - These - helper files are part of an elaborate hack that will compress the - command line in the makefile and then uncompress it safely. - We're - not proud of it, but it does fix the problem. - If you have any better suggestions, we're all ears! :-) -- Q: - I want to see the output of the commands that make runs, - like in the old build. How do I do that? -
-
- A: - You specify theLOGvariable to make. There are - several log levels: --- --
-- -
-warn— Default and very quiet. -- -
-info— Shows more progress information - than warn. -- -
-debug— Echos all command lines and - prints all macro calls for compilation definitions. -- -
-trace— Echos all $(shell) command - lines as well. -- Q: - When do I have to re-run
- -configure? -
- A: - Normally you will runconfigureonly once for creating a - configuration. - You need to re-run configuration only if you want to change any - configuration options, - or if you pull down changes to theconfigurescript. -- Q: - I have added a new source file. Do I need to modify the makefiles? -
- -
- A: - Normally, no. If you want to create e.g. a new native - library, - you will need to modify the makefiles. But for normal file - additions or removals, no changes are needed. There are certan - exceptions for some native libraries where the source files are spread - over many directories which also contain sources for other - libraries. In these cases it was simply easier to create include lists - rather than excludes. -- Q: - When I run
- -configure --help, I see many strange options, - like--dvidir. What is this? -
- A: - Configure provides a slew of options by default, to all projects - that use autoconf. Most of them are not used in OpenJDK, - so you can safely ignore them. To list only OpenJDK specific features, - useconfigure --help=shortinstead. -- Q: -
- -configureprovides OpenJDK-specific features such as ---with-builddeps-serverthat are not - described in this document. What about those? -
- A: - Try them out if you like! But be aware that most of these are - experimental features. - Many of them don't do anything at all at the moment; the option - is just a placeholder. Others depend on - pieces of code or infrastructure that is currently - not ready for prime time. -- Q: - How will you make sure you don't break anything? -
- -
- A: - We have a script that compares the result of the new build system - with the result of the old. For most part, we aim for (and achieve) - byte-by-byte identical output. There are however technical issues - with e.g. native binaries, which might differ in a byte-by-byte - comparison, even - when building twice with the old build system. - For these, we compare relevant aspects - (e.g. the symbol table and file size). - Note that we still don't have 100% - equivalence, but we're close. -- Q: - I noticed this thing X in the build that looks very broken by design. - Why don't you fix it? -
- -
- A: - Our goal is to produce a build output that is as close as - technically possible to the old build output. - If things were weird in the old build, - they will be weird in the new build. - Often, things were weird before due to obscurity, - but in the new build system the weird stuff comes up to the surface. - The plan is to attack these things at a later stage, - after the new build system is established. -- Q: - The code in the new build system is not that well-structured. - Will you fix this? -
- -
- A: - Yes! The new build system has grown bit by bit as we converted - the old system. When all of the old build system is converted, - we can take a step back and clean up the structure of the new build - system. Some of this we plan to do before replacing the old build - system and some will need to wait until after. -- Q: - Is anything able to use the results of the new build's default make target? -
- -
- A: - Yes, this is the minimal (or roughly minimal) - set of compiled output needed for a developer to actually - execute the newly built JDK. The idea is that in an incremental - development fashion, when doing a normal make, - you should only spend time recompiling what's changed - (making it purely incremental) and only do the work that's - needed to actually run and test your code. - The packaging stuff that is part of theimages- target is not needed for a normal developer who wants to - test his new code. Even if it's quite fast, it's still unnecessary. - We're targeting sub-second incremental rebuilds! ;-) - (Or, well, at least single-digit seconds...) -- Q: - I usually set a specific environment variable when building, - but I can't find the equivalent in the new build. - What should I do? -
- -
- A: - It might very well be that we have neglected to add support for - an option that was actually used from outside the build system. - Email us and we will add support for it! -Build Performance Tips
-- -- -Building OpenJDK requires a lot of horsepower. - Some of the build tools can be adjusted to utilize more or less - of resources such as - parallel threads and memory. - The
- -configurescript analyzes your system and selects reasonable - values for such options based on your hardware. - If you encounter resource problems, such as out of memory conditions, - you can modify the detected values with:-
- -- -
---with-num-cores- — - number of cores in the build system, - e.g.--with-num-cores=8-- -
---with-memory-size- — memory (in MB) available in the build system, - e.g.--with-memory-size=1024-It might also be necessary to specify the JVM arguments passed - to the Bootstrap JDK, using e.g. -
- - ---with-boot-jdk-jvmargs="-Xmx8G -enableassertions". - Doing this will override the default JVM arguments - passed to the Bootstrap JDK.One of the top goals of the new build system is to improve the - build performance and decrease the time needed to build. This will - soon also apply to the java compilation when the Smart Javac wrapper - is fully supported.
- -At the end of a successful execution of
- -configure, - you will get a performance summary, - indicating how well the build will perform. Here you will - also get performance hints. - If you want to build fast, pay attention to those!Building with ccache
- -The OpenJDK build supports building with ccache - when using gcc or clang. Using ccache can - radically speed up compilation of native code if - you often rebuild the same sources. Your milage - may vary however so we recommend evaluating it for - yourself. To enable it, make sure it's on the path - and configure with
- ---enable-ccache.Building on local disk
- -If you are using network shares, e.g. via NFS, for your source code, - make sure the build directory is situated on local disk. - The performance - penalty is extremely high for building on a network share, - close to unusable.
- -Building only one JVM
- -The old build builds multiple JVMs on 32-bit systems (client and - server; and on Windows kernel as well). In the new build we have - changed this default to only build server when it's available. This - improves build times for those not interested in multiple JVMs. To - mimic the old behavior on platforms that support it, - use
- ---with-jvm-variants=client,server.Selecting the number of cores to build on
- -By default,
- -configurewill analyze your machine and run the make - process in parallel with as many threads as you have cores. This - behavior can be overridden, either "permanently" (on aconfigure- basis) using--with-num-cores=Nor for a single build - only (on a make basis), usingmake JOBS=N.If you want to make a slower build just this time, to save some CPU - power for other processes, you can run - e.g.
- -make JOBS=2. This will force the makefiles - to only run 2 parallel processes, or evenmake JOBS=1- which will disable parallelism.If you want to have it the other way round, namely having slow - builds default and override with fast if you're - impatient, you should call
- -configurewith ---with-num-cores=2, making 2 the default. - If you want to run with more - cores, runmake JOBS=8Troubleshooting
-- -- -Solving build problems
- -- If the build fails (and it's not due to a compilation error in - a source file you've changed), the first thing you should do - is to re-run the build with more verbosity. - Do this by adding- -LOG=debugto your make command line. -
- The build log (with both stdout and stderr intermingled, - basically the same as you see on your console) can be found as -build.login your build directory. -
- You can ask for help on build problems with the new build system - on either the - - build-dev - or the - - build-infra-dev - mailing lists. Please include the relevant parts - of the build log. -
- A build can fail for any number of reasons. - Most failures - are a result of trying to build in an environment in which all the - pre-build requirements have not been met. - The first step in - troubleshooting a build failure is to recheck that you have satisfied - all the pre-build requirements for your platform. - Scanning theconfigurelog is a good first step, making - sure that what it found makes sense for your system. - Look for strange error messages or any difficulties that -configurehad in finding things. -
- Some of the more common problems with builds are briefly - described - below, with suggestions for remedies. --
-- - Corrupted Bundles on Windows: -
-- Some virus scanning software has been known to - corrupt the - downloading of zip bundles. - It may be necessary to disable the 'on access' or - 'real time' - virus scanning features to prevent this corruption. - This type of "real time" virus scanning can also - slow down the - build process significantly. - Temporarily disabling the feature, or excluding the build - output directory may be necessary to get correct and - faster builds. --- - Slow Builds: -
-- If your build machine seems to be overloaded from too many - simultaneous C++ compiles, try setting the --JOBS=1on themakecommand line. - Then try increasing the count slowly to an acceptable - level for your system. Also: -- Creating the javadocs can be very slow, - if you are running - javadoc, consider skipping that step. --
- Faster CPUs, more RAM, and a faster DISK usually helps. - The VM build tends to be CPU intensive - (many C++ compiles), - and the rest of the JDK will often be disk intensive. -
- Faster compiles are possible using a tool called - ccache. -- - File time issues: -
-- If you see warnings that refer to file time stamps, e.g. --- Warning message:- These warnings can occur when the clock on the build - machine is out of - sync with the timestamps on the source files. - Other errors, apparently - unrelated but in fact caused by the clock skew, - can occur along with - the clock skew warnings. - These secondary errors may tend to obscure the - fact that the true root cause of the problem - is an out-of-sync clock. -- File `xxx' has modification time in - the future.-
- Warning message:Clock skew detected. - Your build may - be incomplete.-- If you see these warnings, reset the clock on the - build - machine, run "
gmake clobber" - or delete the directory - containing the build output, and restart the - build from the beginning. -- - Error message: -
-Trouble writing out table to disk-- Increase the amount of swap space on your build machine. - This could be caused by overloading the system and - it may be necessary to use: ---- to reduce the load on the system. -make JOBS=1-- - Error Message: -
-libstdc++ not found:-- This is caused by a missing libstdc++.a library. - This is installed as part of a specific package - (e.g. libstdc++.so.devel.386). - By default some 64-bit Linux versions (e.g. Fedora) - only install the 64-bit version of the libstdc++ package. - Various parts of the JDK build require a static - link of the C++ runtime libraries to allow for maximum - portability of the built images. --- - Linux Error Message: -
-cannot restore segment prot after reloc-- This is probably an issue with SELinux (See - - http://en.wikipedia.org/wiki/SELinux). - Parts of the VM is built without the--fPICfor - performance reasons. -- To completely disable SELinux: -
-
-- -
$ su root- -
# system-config-securitylevel- -
In the window that appears, select the SELinux tab- -
Disable SELinux- Alternatively, instead of completely disabling it you could - disable just this one check. -
-
-- Select System->Administration->SELinux Management
-- In the SELinux Management Tool which appears, - select "Boolean" from the menu on the left
-- Expand the "Memory Protection" group
-- Check the first item, labeled - "Allow all unconfined executables to use - libraries requiring text relocation ..."
-- - Windows Error Messages: -
-
-*** fatal error - couldn't allocate heap, ...-
-rm fails with "Directory not empty"-
-unzip fails with "cannot create ... Permission denied"-
-unzip fails with "cannot create ... Error 50"-
-- The CYGWIN software can conflict with other non-CYGWIN - software. See the CYGWIN FAQ section on - - BLODA (applications that interfere with CYGWIN). --- - Windows Error Message:
-spawn failed-- Try rebooting the system, or there could be some kind of - issue with the disk or disk partition being used. - Sometimes it comes with a "Permission Denied" message. --
- - The Makefiles in the OpenJDK are only valid when used with the - GNU version of the utility command- - -make- (usually calledgmakeon Solaris). - A few notes about using GNU make: --
-- - You need GNU make version 3.81 or newer. On Windows 4.0 or - newer is recommended. - If the GNU make utility on your systems is not of a suitable - version see "Building GNU make". -
-- - Place the location of the GNU make binary in the -
-PATH. -- - Solaris: - Do NOT use
-/usr/bin/makeon Solaris. - If your Solaris system has the software - from the Solaris Developer Companion CD installed, - you should try and usegmake- which will be located in either the -/usr/bin,/opt/sfw/binor -/usr/sfw/bindirectory. -- - Windows: - Make sure you start your build inside a bash shell. -
-- - Mac OS X: - The XCode "command line tools" must be installed on your Mac. -
-- Information on GNU make, and access to ftp download sites, are - available on the - - GNU make web site - . - The latest source to GNU make is available at - - ftp.gnu.org/pub/gnu/make/. -
- -Building GNU make
-- First step is to get the GNU make 3.81 or newer source from - - ftp.gnu.org/pub/gnu/make/. - Building is a little different depending on the OS but is - basically done with: -- ---bash ./configure-
-make-
- -- - - - +Minimum Build Environments
-- This file often describes specific requirements for what we - call the - "minimum build environments" (MBE) for this - specific release of the JDK. - What is listed below is what the Oracle Release - Engineering Team will use to build the Oracle JDK product. - Building with the MBE will hopefully generate the most compatible - bits that install on, and run correctly on, the most variations - of the same base OS and hardware architecture. - In some cases, these represent what is often called the - least common denominator, but each Operating System has different - aspects to it. -- - -- In all cases, the Bootstrap JDK version minimum is critical, - we cannot guarantee builds will work with older Bootstrap JDK's. - Also in all cases, more RAM and more processors is better, - the minimums listed below are simply recommendations. -
- With Solaris and Mac OS X, the version listed below is the - oldest release we can guarantee builds and works, and the - specific version of the compilers used could be critical. -
- With Windows the critical aspect is the Visual Studio compiler - used, which due to it's runtime, generally dictates what Windows - systems can do the builds and where the resulting bits can - be used.
- NOTE: We expect a change here off these older Windows OS releases - and to a 'less older' one, probably Windows 2008R2 X64. -- With Linux, it was just a matter of picking a - stable distribution that is a good representative for Linux - in general.
- NOTE: We expect a change here from Fedora 9 to something else, - but it has not been completely determined yet, possibly - Ubuntu 12.04 X64, unbiased community feedback would be welcome on - what a good choice would be here. -- It is understood that most developers will NOT be using these - specific versions, and in fact creating these specific versions - may be difficult due to the age of some of this software. - It is expected that developers are more often using the more - recent releases and distributions of these operating systems. -
- Compilation problems with newer or different C/C++ compilers is a - common problem. - Similarly, compilation problems related to changes to the -
-/usr/includeor system header files is also a - common problem with older, newer, or unreleased OS versions. - Please report these types of problems as bugs so that they - can be dealt with accordingly. -- -
-- - - -Base OS and Architecture -OS -C/C++ Compiler -Bootstrap JDK -Processors -RAM Minimum -DISK Needs -- -Linux X86 (32-bit) and X64 (64-bit) -Oracle Enterprise Linux 6.4 -gcc 4.8.2 -JDK 8 -2 or more -1 GB -6 GB -- -Solaris SPARCV9 (64-bit) -Solaris 10 Update 10 -Studio 12 Update 3 + patches -JDK 8 -4 or more -4 GB -8 GB -- -Solaris X64 (64-bit) -Solaris 10 Update 10 -Studio 12 Update 3 + patches -JDK 8 -4 or more -4 GB -8 GB -- -Windows X86 (32-bit) -Windows Server 2012 R2 x64 -Microsoft Visual Studio C++ 2013 Professional Edition -JDK 8 -2 or more -2 GB -6 GB -- -Windows X64 (64-bit) -Windows Server 2012 R2 x64 -Microsoft Visual Studio C++ 2013 Professional Edition -JDK 8 -2 or more -2 GB -6 GB -- - -Mac OS X X64 (64-bit) -Mac OS X 10.9 "Mavericks" -XCode 5.1.1 or newer -JDK 8 -2 or more -4 GB -6 GB -
-Specific Developer Build Environments
-- We won't be listing all the possible environments, but - we will try to provide what information we have available to us. -- -- NOTE: The community can help out by updating - this part of the document. - - -
Fedora
-- After installing the latest - Fedora - you need to install several build dependencies. - The simplest way to do it is to execute the - following commands as user- - -root: ---yum-builddep java-1.7.0-openjdk-
-yum install gcc gcc-c++-- In addition, it's necessary to set a few environment - variables for the build: -
--export LANG=C-
-export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}"-CentOS 5.5
-- After installing - CentOS 5.5 - you need to make sure you have - the following Development bundles installed: -- ----
-- Development Libraries
-- Development Tools
-- Java Development
-- X Software Development (Including XFree86-devel)
-- Plus the following packages: -
---
-- cups devel: Cups Development Package
-- alsa devel: Alsa Development Package
-- Xi devel: libXi.so Development Package
-- The freetype 2.3 packages don't seem to be available, - but the freetype 2.3 sources can be downloaded, built, - and installed easily enough from - - the freetype site. - Build and install with something like: -
--bash ./configure-
-make-
-sudo -u root make install-- Mercurial packages could not be found easily, but a Google - search should find ones, and they usually include Python if - it's needed. -
Debian 5.0 (Lenny)
-- After installing Debian 5 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands as user- -root: ---aptitude build-dep openjdk-7-
-aptitude install openjdk-7-jdk libmotif-dev-- In addition, it's necessary to set a few environment - variables for the build: -
--export LANG=C-
-export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"-Ubuntu 12.04
-- After installing Ubuntu 12.04 - you need to install several build dependencies. The simplest - way to do it is to execute the following commands: -- ---sudo aptitude build-dep openjdk-7-
-sudo aptitude install openjdk-7-jdk-- In addition, it's necessary to set a few environment - variables for the build: -
--export LANG=C-
-export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"-OpenSUSE 11.1
-- After installing OpenSUSE 11.1 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands: -- ---sudo zypper source-install -d java-1_7_0-openjdk-
-sudo zypper install make-- In addition, it is necessary to set a few environment - variables for the build: -
--export LANG=C-
-export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}"-- Finally, you need to unset the
JAVA_HOME- environment variable: ---export -n JAVA_HOME-Mandriva Linux One 2009 Spring
-- After installing Mandriva - Linux One 2009 Spring - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands as user- -root: ---urpmi java-1.7.0-openjdk-devel make gcc gcc-c++ - freetype-devel zip unzip libcups2-devel libxrender1-devel - libalsa2-devel libstc++-static-devel libxtst6-devel - libxi-devel-- In addition, it is necessary to set a few environment - variables for the build: -
--export LANG=C-
-export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}"-OpenSolaris 2009.06
-- After installing OpenSolaris 2009.06 - you need to install several build dependencies. - The simplest way to install the build dependencies is to - execute the following commands: -- ---pfexec pkg install SUNWgmake SUNWj7dev - sunstudioexpress SUNWcups SUNWzip SUNWunzip SUNWxwhl - SUNWxorg-headers SUNWaudh SUNWfreetype2-- In addition, it is necessary to set a few environment - variables for the build: -
--export LANG=C-
-export PATH="/opt/SunStudioExpress/bin:${PATH}"-
End of OpenJDK README-builds.html document.
Please come again!
-
Before even attempting to use a system to build the OpenJDK there are some very +basic system setups needed. For all systems:
+ +Be sure the GNU make utility is version 3.81 (4.0 on windows) or newer, e.g.
+run "make -version"
Install a Bootstrap JDK. All OpenJDK builds require access to a previously +released JDK called the bootstrap JDK or boot JDK. The general rule is +that the bootstrap JDK must be an instance of the previous major release of +the JDK. In addition, there may be a requirement to use a release at or +beyond a particular update level.
+ +Building JDK 9 requires JDK 8. JDK 9 developers should not use JDK 9 as +the boot JDK, to ensure that JDK 9 dependencies are not introduced into the +parts of the system that are built with JDK 8.
+ +The JDK 8 binaries can be downloaded from Oracle's JDK 8 download
+site.
+For build performance reasons it is very important that this bootstrap JDK
+be made available on the local disk of the machine doing the build. You
+should add its bin directory to the PATH environment variable. If
+configure has any issues finding this JDK, you may need to use the
+configure option --with-boot-jdk.
Ensure that GNU make, the Bootstrap JDK, and the compilers are all in your +PATH environment variable.
And for specific systems:
+ +Linux
+ +Install all the software development packages needed including +alsa, freetype, cups, and +xrender. See specific system packages.
Solaris
+ +Install all the software development packages needed including Studio +Compilers, freetype, cups, and +xrender. See specific system packages.
Windows
+ +Mac OS X
+ +Install XCode 4.5.2 and also +install the "Command line tools" found under the preferences pane +"Downloads"
With Linux, try and favor the system packages over building your own or getting +packages from other areas. Most Linux builds should be possible with the +system's available packages.
+ +Note that some Linux systems have a habit of pre-populating your environment
+variables for you, for example JAVA_HOME might get pre-defined for you to
+refer to the JDK installed on your Linux system. You will need to unset
+JAVA_HOME. It's a good idea to run env and verify the environment variables
+you are getting from the default system settings make sense for building the
+OpenJDK.
At a minimum, the Studio 12 Update 1 Compilers (containing +version 5.10 of the C and C++ compilers) is required, including specific +patches.
+ +The Solaris SPARC patch list is:
+ +The Solaris X86 patch list is:
+ +Place the bin directory in PATH.
The Oracle Solaris Studio Express compilers at: Oracle Solaris Studio Express +Download site are also an option, although these compilers +have not been extensively used yet.
+ + + +Building on Windows requires a Unix-like environment, notably a Unix-like +shell. There are several such environments available of which +Cygwin and +MinGW/MSYS are currently supported for the +OpenJDK build. One of the differences of these systems from standard Windows +tools is the way they handle Windows path names, particularly path names which +contain spaces, backslashes as path separators and possibly drive letters. +Depending on the use case and the specifics of each environment these path +problems can be solved by a combination of quoting whole paths, translating +backslashes to forward slashes, escaping backslashes with additional +backslashes and translating the path names to their "8.3" +version.
+ + + +CYGWIN is an open source, Linux-like environment which tries to emulate a
+complete POSIX layer on Windows. It tries to be smart about path names and can
+usually handle all kinds of paths if they are correctly quoted or escaped
+although internally it maps drive letters <drive>: to a virtual directory
+/cygdrive/<drive>.
You can always use the cygpath utility to map pathnames with spaces or the
+backslash character into the C:/ style of pathname (called 'mixed'), e.g.
+cygpath -s -m "<path>".
Note that the use of CYGWIN creates a unique problem with regards to setting
+PATH. Normally on Windows the PATH variable contains directories
+separated with the ";" character (Solaris and Linux use ":"). With CYGWIN, it
+uses ":", but that means that paths like "C:/path" cannot be placed in the
+CYGWIN version of PATH and instead CYGWIN uses something like
+/cygdrive/c/path which CYGWIN understands, but only CYGWIN understands.
The OpenJDK build requires CYGWIN version 1.7.16 or newer. Information about +CYGWIN can be obtained from the CYGWIN website at +www.cygwin.com.
+ +By default CYGWIN doesn't install all the tools required for building the +OpenJDK. Along with the default installation, you need to install the following +tools.
+ +++ ++ +
++ + + +Binary Name +Category +Package +Description ++ +ar.exe +Devel +binutils +The GNU assembler, linker and binary utilities ++ +make.exe +Devel +make +The GNU version of the 'make' utility built for CYGWIN ++ +m4.exe +Interpreters +m4 +GNU implementation of the traditional Unix macro processor ++ +cpio.exe +Utils +cpio +A program to manage archives of files ++ +gawk.exe +Utils +awk +Pattern-directed scanning and processing language ++ +file.exe +Utils +file +Determines file type using 'magic' numbers ++ +zip.exe +Archive +zip +Package and compress (archive) files ++ +unzip.exe +Archive +unzip +Extract compressed files in a ZIP archive ++ + +free.exe +System +procps +Display amount of free and used memory in the system +
Note that the CYGWIN software can conflict with other non-CYGWIN software on +your Windows system. CYGWIN provides a FAQ for known issues and problems, of particular interest is the +section on BLODA (applications that interfere with +CYGWIN).
+ + + +MinGW ("Minimalist GNU for Windows") is a collection of free Windows specific
+header files and import libraries combined with GNU toolsets that allow one to
+produce native Windows programs that do not rely on any 3rd-party C runtime
+DLLs. MSYS is a supplement to MinGW which allows building applications and
+programs which rely on traditional UNIX tools to be present. Among others this
+includes tools like bash and make. See MinGW/MSYS for more information.
Like Cygwin, MinGW/MSYS can handle different types of path formats. They are
+internally converted to paths with forward slashes and drive letters
+<drive>: replaced by a virtual directory /<drive>. Additionally, MSYS
+automatically detects binaries compiled for the MSYS environment and feeds them
+with the internal, Unix-style path names. If native Windows applications are
+called from within MSYS programs their path arguments are automatically
+converted back to Windows style path names with drive letters and backslashes
+as path separators. This may cause problems for Windows applications which use
+forward slashes as parameter separator (e.g. cl /nologo /I) because MSYS may
+wrongly replace such parameters by drive letters.
In addition to the tools which will be installed by default, you have to
+manually install the msys-zip and msys-unzip packages. This can be easily
+done with the MinGW command line installer:
mingw-get.exe install msys-zip
+ mingw-get.exe install msys-unzip
+The 32-bit and 64-bit OpenJDK Windows build requires Microsoft Visual Studio
+C++ 2013 (VS2013) Professional Edition or Express compiler. The compiler and
+other tools are expected to reside in the location defined by the variable
+VS120COMNTOOLS which is set by the Microsoft Visual Studio installer.
Only the C++ part of VS2013 is needed. Try to let the installation go to the +default install directory. Always reboot your system after installing VS2013. +The system environment variable VS120COMNTOOLS should be set in your +environment.
+ +Make sure that TMP and TEMP are also set in the environment and refer to
+Windows paths that exist, like C:\temp, not /tmp, not /cygdrive/c/temp,
+and not C:/temp. C:\temp is just an example, it is assumed that this area
+is private to the user, so by default after installs you should see a unique
+user path in these variables.
Make sure you get the right XCode version.
+ +The basic invocation of the configure script looks like:
++ ++
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
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. When this
+happens, read more below in the configure options.
Some examples:
+ +++ + + +Windows 32bit build with freetype specified:
+ +
+bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target- +bits=32Debug 64bit Build:
+
+bash ./configure --enable-debug --with-target-bits=64
Complete details on all the OpenJDK configure options can be seen with:
++ ++
bash ./configure --help=short
Use -help to see all the configure options available. You can generate any
+number of different configurations, e.g. debug, release, 32, 64, etc.
Some of the more commonly used configure options are:
++ + + ++
--enable-debug
+ set the debug level to fastdebug (this is a shorthand for--with-debug- + level=fastdebug)
++ + + ++ +
--with-alsa=path
+ select the location of the Advanced Linux Sound Architecture (ALSA)Version 0.9.1 or newer of the ALSA files are required for building the + OpenJDK on Linux. These Linux files are usually available from an "alsa" of + "libasound" development package, and it's highly recommended that you try + and use the package provided by the particular version of Linux that you are + using.
+ ++ +
--with-boot-jdk=path
+ select the Bootstrap JDK+ +
--with-boot-jdk-jvmargs="args"
+ provide the JVM options to be used to run the Bootstrap JDK+ +
--with-cacerts=path
+ select the path to the cacerts file.See Certificate Authority on Wikipedia for a better understanding of the Certificate + Authority (CA). A certificates file named "cacerts" represents a system-wide + keystore with CA certificates. In JDK and JRE binary bundles, the "cacerts" + file contains root CA certificates from several public CAs (e.g., VeriSign, + Thawte, and Baltimore). The source contain a cacerts file without CA root + certificates. Formal JDK builders will need to secure permission from each + public CA and include the certificates into their own custom cacerts file. + Failure to provide a populated cacerts file will result in verification + errors of a certificate chain during runtime. By default an empty cacerts + file is provided and that should be fine for most JDK developers.
+
++ + + ++ +
--with-cups=path
+ select the CUPS install locationThe Common UNIX Printing System (CUPS) Headers are required for building the + OpenJDK on Solaris and Linux. The Solaris header files can be obtained by + installing the package SFWcups from the Solaris Software Companion + CD/DVD, these often will be installed into the directory
+ +/opt/sfw/cups.The CUPS header files can always be downloaded from + www.cups.org.
+ ++ +
--with-cups-include=path
+ select the CUPS include directory location+ +
--with-debug-level=level
+ select the debug information level of release, fastdebug, or slowdebug+
--with-dev-kit=path
+ select location of the compiler install or developer install location
++ + + ++ +
--with-freetype=path
+ select the freetype files to use.Expecting the freetype libraries under
+ +lib/and the headers under +include/.Version 2.3 or newer of FreeType is required. On Unix systems required files + can be available as part of your distribution (while you still may need to + upgrade them). Note that you need development version of package that + includes both the FreeType library and header files.
+ +You can always download latest FreeType version from the FreeType + website. Building the freetype 2 libraries from + scratch is also possible, however on Windows refer to the Windows FreeType + DLL build instructions.
+ +Note that by default FreeType is built with byte code hinting support + disabled due to licensing restrictions. In this case, text appearance and + metrics are expected to differ from Sun's official JDK build. See the + SourceForge FreeType2 Home Page + for more information.
+ ++ +
--with-import-hotspot=path
+ select the location to find hotspot binaries from a previous build to avoid + building hotspot+ +
--with-target-bits=arg
+ select 32 or 64 bit build+ +
--with-jvm-variants=variants
+ select the JVM variants to build from, comma separated list that can + include: server, client, kernel, zero and zeroshark+ +
--with-memory-size=size
+ select the RAM size that GNU make will think this system has+ +
--with-msvcr-dll=path
+ select themsvcr100.dllfile to include in the Windows builds (C/C++ + runtime library for Visual Studio).This is usually picked up automatically from the redist directories of + Visual Studio 2013.
+ ++
--with-num-cores=cores
+ select the number of cores to use (processor count or CPU count)
++ ++ +
--with-x=path
+ select the location of the X11 and xrender files.The XRender Extension Headers are required for building the OpenJDK on + Solaris and Linux. The Linux header files are usually available from a + "Xrender" development package, it's recommended that you try and use the + package provided by the particular distribution of Linux that you are using. + The Solaris XRender header files is included with the other X11 header files + in the package SFWxwinc on new enough versions of Solaris and will be + installed in
+/usr/X11/include/X11/extensions/Xrender.hor +/usr/openwin/share/include/X11/extensions/Xrender.h
The basic invocation of the make utility looks like:
++ ++
make all
This will start the build to the output directory containing the
+"configuration" that was created by the configure script. Run make help for
+more information on the available targets.
There are some of the make targets that are of general interest:
+ +++ +empty
+ +
+ build everything but no images+ +
all
+ build everything including images+ +
all-conf
+ build all configurations+ +
images
+ create complete j2sdk and j2re images+ +
install
+ install the generated images locally, typically in/usr/local+ +
clean
+ remove all files generated by make, but not those generated byconfigure+ +
dist-clean
+ remove all files generated by both andconfigure(basically killing the + configuration)+
help
+ give some help on usingmake, including some interesting make targets
When the build is completed, you should see the generated binaries and
+associated files in the j2sdk-image directory in the output directory. In
+particular, the build/*/images/j2sdk-image/bin directory should contain
+executables for the OpenJDK tools and utilities for that configuration. The
+testing tool jtreg will be needed and can be found at: the jtreg
+site. The provided regression tests in the
+repositories can be run with the command:
++ ++
cd test && make PRODUCT_HOME=`pwd`/../build/*/images/j2sdk-image all
Q: The generated-configure.sh file looks horrible! How are you going to
+edit it?
+A: The generated-configure.sh file is generated (think "compiled") by the
+autoconf tools. The source code is in configure.ac and various .m4 files in
+common/autoconf, which are much more readable.
Q: Why is the generated-configure.sh file checked in, if it is
+generated?
+A: If it was not generated, every user would need to have the autoconf
+tools installed, and re-generate the configure file as the first step. Our
+goal is to minimize the work needed to be done by the user to start building
+OpenJDK, and to minimize the number of external dependencies required.
Q: Do you require a specific version of autoconf for regenerating
+generated-configure.sh?
+A: Yes, version 2.69 is required and should be easy enough to aquire on all
+supported operating systems. The reason for this is to avoid large spurious
+changes in generated-configure.sh.
Q: How do you regenerate generated-configure.sh after making changes to
+the input files?
+A: Regnerating generated-configure.sh should always be done using the
+script common/autoconf/autogen.sh to ensure that the correct files get
+updated. This script should also be run after mercurial tries to merge
+generated-configure.sh as a merge of the generated file is not guaranteed to
+be correct.
Q: What are the files in common/makefiles/support/* for? They look like
+gibberish.
+A: They are a somewhat ugly hack to compensate for command line length
+limitations on certain platforms (Windows, Solaris). Due to a combination of
+limitations in make and the shell, command lines containing too many files will
+not work properly. These helper files are part of an elaborate hack that will
+compress the command line in the makefile and then uncompress it safely. We're
+not proud of it, but it does fix the problem. If you have any better
+suggestions, we're all ears! :-)
Q: I want to see the output of the commands that make runs, like in the old
+build. How do I do that?
+A: You specify the LOG variable to make. There are several log levels:
warn -- Default and very quiet.info -- Shows more progress information than warn.debug -- Echos all command lines and prints all macro calls for
+compilation definitions.trace -- Echos all $(shell) command lines as well.Q: When do I have to re-run configure?
+A: Normally you will run configure only once for creating a
+configuration. You need to re-run configuration only if you want to change any
+configuration options, or if you pull down changes to the configure script.
Q: I have added a new source file. Do I need to modify the makefiles?
+A: Normally, no. If you want to create e.g. a new native library, you will
+need to modify the makefiles. But for normal file additions or removals, no
+changes are needed. There are certan exceptions for some native libraries where
+the source files are spread over many directories which also contain sources
+for other libraries. In these cases it was simply easier to create include
+lists rather than excludes.
Q: When I run configure --help, I see many strange options, like
+--dvidir. What is this?
+A: Configure provides a slew of options by default, to all projects that
+use autoconf. Most of them are not used in OpenJDK, so you can safely ignore
+them. To list only OpenJDK specific features, use configure --help=short
+instead.
Q: configure provides OpenJDK-specific features such as --with-
+builddeps-server that are not described in this document. What about those?
+A: Try them out if you like! But be aware that most of these are
+experimental features. Many of them don't do anything at all at the moment; the
+option is just a placeholder. Others depend on pieces of code or infrastructure
+that is currently not ready for prime time.
Q: How will you make sure you don't break anything?
+A: We have a script that compares the result of the new build system with
+the result of the old. For most part, we aim for (and achieve) byte-by-byte
+identical output. There are however technical issues with e.g. native binaries,
+which might differ in a byte-by-byte comparison, even when building twice with
+the old build system. For these, we compare relevant aspects (e.g. the symbol
+table and file size). Note that we still don't have 100% equivalence, but we're
+close.
Q: I noticed this thing X in the build that looks very broken by design.
+Why don't you fix it?
+A: Our goal is to produce a build output that is as close as technically
+possible to the old build output. If things were weird in the old build, they
+will be weird in the new build. Often, things were weird before due to
+obscurity, but in the new build system the weird stuff comes up to the surface.
+The plan is to attack these things at a later stage, after the new build system
+is established.
Q: The code in the new build system is not that well-structured. Will you
+fix this?
+A: Yes! The new build system has grown bit by bit as we converted the old
+system. When all of the old build system is converted, we can take a step back
+and clean up the structure of the new build system. Some of this we plan to do
+before replacing the old build system and some will need to wait until after.
Q: Is anything able to use the results of the new build's default make
+target?
+A: Yes, this is the minimal (or roughly minimal) set of compiled output
+needed for a developer to actually execute the newly built JDK. The idea is
+that in an incremental development fashion, when doing a normal make, you
+should only spend time recompiling what's changed (making it purely
+incremental) and only do the work that's needed to actually run and test your
+code. The packaging stuff that is part of the images target is not needed for
+a normal developer who wants to test his new code. Even if it's quite fast,
+it's still unnecessary. We're targeting sub-second incremental rebuilds! ;-)
+(Or, well, at least single-digit seconds...)
Q: I usually set a specific environment variable when building, but I can't
+find the equivalent in the new build. What should I do?
+A: It might very well be that we have neglected to add support for an
+option that was actually used from outside the build system. Email us and we
+will add support for it!
Building OpenJDK requires a lot of horsepower. Some of the build tools can be
+adjusted to utilize more or less of resources such as parallel threads and
+memory. The configure script analyzes your system and selects reasonable
+values for such options based on your hardware. If you encounter resource
+problems, such as out of memory conditions, you can modify the detected values
+with:
--with-num-cores -- number of cores in the build system, e.g.
+--with-num-cores=8--with-memory-size -- memory (in MB) available in the build system,
+e.g. --with-memory-size=1024It might also be necessary to specify the JVM arguments passed to the Bootstrap
+JDK, using e.g. --with-boot-jdk-jvmargs="-Xmx8G -enableassertions". Doing
+this will override the default JVM arguments passed to the Bootstrap JDK.
One of the top goals of the new build system is to improve the build +performance and decrease the time needed to build. This will soon also apply to +the java compilation when the Smart Javac wrapper is fully supported.
+ +At the end of a successful execution of configure, you will get a performance
+summary, indicating how well the build will perform. Here you will also get
+performance hints. If you want to build fast, pay attention to those!
The OpenJDK build supports building with ccache when using gcc or clang. Using
+ccache can radically speed up compilation of native code if you often rebuild
+the same sources. Your milage may vary however so we recommend evaluating it
+for yourself. To enable it, make sure it's on the path and configure with
+--enable-ccache.
If you are using network shares, e.g. via NFS, for your source code, make sure +the build directory is situated on local disk. The performance penalty is +extremely high for building on a network share, close to unusable.
+ +The old build builds multiple JVMs on 32-bit systems (client and server; and on
+Windows kernel as well). In the new build we have changed this default to only
+build server when it's available. This improves build times for those not
+interested in multiple JVMs. To mimic the old behavior on platforms that
+support it, use --with-jvm-variants=client,server.
By default, configure will analyze your machine and run the make process in
+parallel with as many threads as you have cores. This behavior can be
+overridden, either "permanently" (on a configure basis) using
+--with-num-cores=N or for a single build only (on a make basis), using
+make JOBS=N.
If you want to make a slower build just this time, to save some CPU power for
+other processes, you can run e.g. make JOBS=2. This will force the makefiles
+to only run 2 parallel processes, or even make JOBS=1 which will disable
+parallelism.
If you want to have it the other way round, namely having slow builds default
+and override with fast if you're impatient, you should call configure with
+--with-num-cores=2, making 2 the default. If you want to run with more cores,
+run make JOBS=8
If the build fails (and it's not due to a compilation error in a source file
+you've changed), the first thing you should do is to re-run the build with more
+verbosity. Do this by adding LOG=debug to your make command line.
The build log (with both stdout and stderr intermingled, basically the same as
+you see on your console) can be found as build.log in your build directory.
You can ask for help on build problems with the new build system on either the +build-dev or the +build-infra-dev +mailing lists. Please include the relevant parts of the build log.
+ +A build can fail for any number of reasons. Most failures are a result of
+trying to build in an environment in which all the pre-build requirements have
+not been met. The first step in troubleshooting a build failure is to recheck
+that you have satisfied all the pre-build requirements for your platform.
+Scanning the configure log is a good first step, making sure that what it
+found makes sense for your system. Look for strange error messages or any
+difficulties that configure had in finding things.
Some of the more common problems with builds are briefly described below, with +suggestions for remedies.
+ +Corrupted Bundles on Windows:
+Some virus scanning software has been known to corrupt the downloading of
+zip bundles. It may be necessary to disable the 'on access' or 'real time'
+virus scanning features to prevent this corruption. This type of 'real time'
+virus scanning can also slow down the build process significantly.
+Temporarily disabling the feature, or excluding the build output directory
+may be necessary to get correct and faster builds.
Slow Builds:
+If your build machine seems to be overloaded from too many simultaneous C++
+compiles, try setting the JOBS=1 on the make command line. Then try
+increasing the count slowly to an acceptable level for your system. Also:
Creating the javadocs can be very slow, if you are running javadoc, consider +skipping that step.
+ +Faster CPUs, more RAM, and a faster DISK usually helps. The VM build tends +to be CPU intensive (many C++ compiles), and the rest of the JDK will often +be disk intensive.
+ +Faster compiles are possible using a tool called +ccache.
File time issues:
+If you see warnings that refer to file time stamps, e.g.
++ +Warning message:
+File 'xxx' has modification time in the future.
+Warning message:Clock skew detected. Your build may be incomplete.
These warnings can occur when the clock on the build machine is out of sync +with the timestamps on the source files. Other errors, apparently unrelated +but in fact caused by the clock skew, can occur along with the clock skew +warnings. These secondary errors may tend to obscure the fact that the true +root cause of the problem is an out-of-sync clock.
+ +If you see these warnings, reset the clock on the build machine, run
+"gmake clobber" or delete the directory containing the build output, and
+restart the build from the beginning.
Error message: Trouble writing out table to disk
+Increase the amount of swap space on your build machine. This could be
+caused by overloading the system and it may be necessary to use:
++ ++
make JOBS=1
to reduce the load on the system.
Error Message: libstdc++ not found:
+This is caused by a missing libstdc++.a library. This is installed as part
+of a specific package (e.g. libstdc++.so.devel.386). By default some 64-bit
+Linux versions (e.g. Fedora) only install the 64-bit version of the
+libstdc++ package. Various parts of the JDK build require a static link of
+the C++ runtime libraries to allow for maximum portability of the built
+images.
Linux Error Message: cannot restore segment prot after reloc
+This is probably an issue with SELinux (See SELinux on
+Wikipedia). Parts of the VM is built
+without the -fPIC for performance reasons.
To completely disable SELinux:
+ +$ su root# system-config-securitylevelIn the window that appears, select the SELinux tabDisable SELinuxAlternatively, instead of completely disabling it you could disable just +this one check.
+ +Windows Error Messages:
+*** fatal error - couldn't allocate heap, ...
+rm fails with "Directory not empty"
+unzip fails with "cannot create ... Permission denied"
+unzip fails with "cannot create ... Error 50"
The CYGWIN software can conflict with other non-CYGWIN software. See the +CYGWIN FAQ section on BLODA (applications that interfere with +CYGWIN).
Windows Error Message: spawn failed
+Try rebooting the system, or there could be some kind of issue with the disk
+or disk partition being used. Sometimes it comes with a "Permission Denied"
+message.
The Makefiles in the OpenJDK are only valid when used with the GNU version of
+the utility command make (usually called gmake on Solaris). A few notes
+about using GNU make:
PATH./usr/bin/make on Solaris. If your Solaris system
+has the software from the Solaris Developer Companion CD installed, you
+should try and use gmake which will be located in either the /usr/bin,
+/opt/sfw/bin or /usr/sfw/bin directory.Information on GNU make, and access to ftp download sites, are available on the +GNU make web site . The latest +source to GNU make is available at +ftp.gnu.org/pub/gnu/make/.
+ + + +First step is to get the GNU make 3.81 or newer source from +ftp.gnu.org/pub/gnu/make/. Building is a +little different depending on the OS but is basically done with:
+ + bash ./configure
+ make
+This file often describes specific requirements for what we call the "minimum +build environments" (MBE) for this specific release of the JDK. What is listed +below is what the Oracle Release Engineering Team will use to build the Oracle +JDK product. Building with the MBE will hopefully generate the most compatible +bits that install on, and run correctly on, the most variations of the same +base OS and hardware architecture. In some cases, these represent what is often +called the least common denominator, but each Operating System has different +aspects to it.
+ +In all cases, the Bootstrap JDK version minimum is critical, we cannot +guarantee builds will work with older Bootstrap JDK's. Also in all cases, more +RAM and more processors is better, the minimums listed below are simply +recommendations.
+ +With Solaris and Mac OS X, the version listed below is the oldest release we +can guarantee builds and works, and the specific version of the compilers used +could be critical.
+ +With Windows the critical aspect is the Visual Studio compiler used, which due +to it's runtime, generally dictates what Windows systems can do the builds and +where the resulting bits can be used.
+ +NOTE: We expect a change here off these older Windows OS releases and to a +'less older' one, probably Windows 2008R2 X64.
+ +With Linux, it was just a matter of picking a stable distribution that is a +good representative for Linux in general.
+ +NOTE: We expect a change here from Fedora 9 to something else, but it has not +been completely determined yet, possibly Ubuntu 12.04 X64, unbiased community +feedback would be welcome on what a good choice would be here.
+ +It is understood that most developers will NOT be using these specific +versions, and in fact creating these specific versions may be difficult due to +the age of some of this software. It is expected that developers are more often +using the more recent releases and distributions of these operating systems.
+ +Compilation problems with newer or different C/C++ compilers is a common
+problem. Similarly, compilation problems related to changes to the
+/usr/include or system header files is also a common problem with older,
+newer, or unreleased OS versions. Please report these types of problems as bugs
+so that they can be dealt with accordingly.
++ ++ +
++ + + +Base OS and Architecture +OS +C/C++ Compiler +Bootstrap JDK +Processors +RAM Minimum +DISK Needs ++ +Linux X86 (32-bit) and X64 (64-bit) +Oracle Enterprise Linux 6.4 +gcc 4.8.2 +JDK 8 +2 or more +1 GB +6 GB ++ +Solaris SPARCV9 (64-bit) +Solaris 10 Update 10 +Studio 12 Update 3 + patches +JDK 8 +4 or more +4 GB +8 GB ++ +Solaris X64 (64-bit) +Solaris 10 Update 10 +Studio 12 Update 3 + patches +JDK 8 +4 or more +4 GB +8 GB ++ +Windows X86 (32-bit) +Windows Server 2012 R2 x64 +Microsoft Visual Studio C++ 2013 Professional Edition +JDK 8 +2 or more +2 GB +6 GB ++ +Windows X64 (64-bit) +Windows Server 2012 R2 x64 +Microsoft Visual Studio C++ 2013 Professional Edition +JDK 8 +2 or more +2 GB +6 GB ++ + +Mac OS X X64 (64-bit) +Mac OS X 10.9 "Mavericks" +XCode 5.1.1 or newer +JDK 8 +2 or more +4 GB +6 GB +
We won't be listing all the possible environments, but we will try to provide +what information we have available to us.
+ +NOTE: The community can help out by updating this part of the document.
+ +After installing the latest Fedora you need to
+install several build dependencies. The simplest way to do it is to execute the
+following commands as user root:
yum-builddep java-1.7.0-openjdk
+ yum install gcc gcc-c++
+In addition, it's necessary to set a few environment variables for the build:
+ + export LANG=C
+ export PATH="/usr/lib/jvm/java-openjdk/bin:${PATH}"
+After installing CentOS 5.5 you need to make sure you +have the following Development bundles installed:
+ +Plus the following packages:
+ +The freetype 2.3 packages don't seem to be available, but the freetype 2.3 +sources can be downloaded, built, and installed easily enough from the +freetype site. Build and install +with something like:
+ + bash ./configure
+ make
+ sudo -u root make install
+Mercurial packages could not be found easily, but a Google search should find +ones, and they usually include Python if it's needed.
+ +After installing Debian 5 you need to install several
+build dependencies. The simplest way to install the build dependencies is to
+execute the following commands as user root:
aptitude build-dep openjdk-7
+ aptitude install openjdk-7-jdk libmotif-dev
+In addition, it's necessary to set a few environment variables for the build:
+ + export LANG=C
+ export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"
+After installing Ubuntu 12.04 you need to install several +build dependencies. The simplest way to do it is to execute the following +commands:
+ + sudo aptitude build-dep openjdk-7
+ sudo aptitude install openjdk-7-jdk
+In addition, it's necessary to set a few environment variables for the build:
+ + export LANG=C
+ export PATH="/usr/lib/jvm/java-7-openjdk/bin:${PATH}"
+After installing OpenSUSE 11.1 you need to install +several build dependencies. The simplest way to install the build dependencies +is to execute the following commands:
+ + sudo zypper source-install -d java-1_7_0-openjdk
+ sudo zypper install make
+In addition, it is necessary to set a few environment variables for the build:
+ + export LANG=C
+ export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:$[PATH}"
+Finally, you need to unset the JAVA_HOME environment variable:
export -n JAVA_HOME`
+After installing Mandriva Linux One 2009 Spring you need
+to install several build dependencies. The simplest way to install the build
+dependencies is to execute the following commands as user root:
urpmi java-1.7.0-openjdk-devel make gcc gcc-c++ freetype-devel zip unzip
+ libcups2-devel libxrender1-devel libalsa2-devel libstc++-static-devel
+ libxtst6-devel libxi-devel
+In addition, it is necessary to set a few environment variables for the build:
+ + export LANG=C
+ export PATH="/usr/lib/jvm/java-1.7.0-openjdk/bin:${PATH}"
+After installing OpenSolaris 2009.06 you need to +install several build dependencies. The simplest way to install the build +dependencies is to execute the following commands:
+ + pfexec pkg install SUNWgmake SUNWj7dev sunstudioexpress SUNWcups SUNWzip
+ SUNWunzip SUNWxwhl SUNWxorg-headers SUNWaudh SUNWfreetype2
+In addition, it is necessary to set a few environment variables for the build:
+ + export LANG=C
+ export PATH="/opt/SunStudioExpress/bin:${PATH}"
+End of the OpenJDK build README document.
+ +Please come again!
+ diff --git a/README-builds.md b/README-builds.md new file mode 100644 index 00000000000..21367477890 --- /dev/null +++ b/README-builds.md @@ -0,0 +1,1263 @@ + +# OpenJDK Build README + +***** + + +## Introduction + +This README file contains build instructions for the +[OpenJDK](http://openjdk.java.net). Building the source code for the OpenJDK +requires a certain degree of technical expertise. + +### !!!!!!!!!!!!!!! THIS IS A MAJOR RE-WRITE of this document. !!!!!!!!!!!!! + +Some Headlines: + + * The build is now a "`configure && make`" style build + * Any GNU make 3.81 or newer should work, except on Windows where 4.0 or newer + is recommended. + * The build should scale, i.e. more processors should cause the build to be + done in less wall-clock time + * Nested or recursive make invocations have been significantly reduced, + as has the total fork/exec or spawning of sub processes during the build + * Windows MKS usage is no longer supported + * Windows Visual Studio `vsvars*.bat` and `vcvars*.bat` files are run + automatically + * Ant is no longer used when building the OpenJDK + * Use of ALT_* environment variables for configuring the build is no longer + supported + +***** + +## Contents + + * [Introduction](#introduction) + * [Use of Mercurial](#hg) + * [Getting the Source](#get_source) + * [Repositories](#repositories) + * [Building](#building) + * [System Setup](#setup) + * [Linux](#linux) + * [Solaris](#solaris) + * [Mac OS X](#macosx) + * [Windows](#windows) + * [Configure](#configure) + * [Make](#make) + * [Testing](#testing) + +***** + + * [Appendix A: Hints and Tips](#hints) + * [FAQ](#faq) + * [Build Performance Tips](#performance) + * [Troubleshooting](#troubleshooting) + * [Appendix B: GNU Make Information](#gmake) + * [Appendix C: Build Environments](#buildenvironments) + +***** + + +## Use of Mercurial + +The OpenJDK sources are maintained with the revision control system +[Mercurial](http://mercurial.selenic.com/wiki/Mercurial). If you are new to +Mercurial, please see the [Beginner Guides](http://mercurial.selenic.com/wiki/ +BeginnersGuides) or refer to the [Mercurial Book](http://hgbook.red-bean.com/). +The first few chapters of the book provide an excellent overview of Mercurial, +what it is and how it works. + +For using Mercurial with the OpenJDK refer to the [Developer Guide: Installing +and Configuring Mercurial](http://openjdk.java.net/guide/ +repositories.html#installConfig) section for more information. + + +### Getting the Source + +To get the entire set of OpenJDK Mercurial repositories use the script +`get_source.sh` located in the root repository: + + hg clone http://hg.openjdk.java.net/jdk9/jdk9 YourOpenJDK + cd YourOpenJDK + bash ./get_source.sh + +Once you have all the repositories, keep in mind that each repository is its +own independent repository. You can also re-run `./get_source.sh` anytime to +pull over all the latest changesets in all the repositories. This set of +nested repositories has been given the term "forest" and there are various +ways to apply the same `hg` command to each of the repositories. For +example, the script `make/scripts/hgforest.sh` can be used to repeat the +same `hg` command on every repository, e.g. + + cd YourOpenJDK + bash ./make/scripts/hgforest.sh status + + +### Repositories + +The set of repositories and what they contain: + + * **. (root)** contains common configure and makefile logic + * **hotspot** contains source code and make files for building the OpenJDK + Hotspot Virtual Machine + * **langtools** contains source code for the OpenJDK javac and language tools + * **jdk** contains source code and make files for building the OpenJDK runtime + libraries and misc files + * **jaxp** contains source code for the OpenJDK JAXP functionality + * **jaxws** contains source code for the OpenJDK JAX-WS functionality + * **corba** contains source code for the OpenJDK Corba functionality + * **nashorn** contains source code for the OpenJDK JavaScript implementation + +### Repository Source Guidelines + +There are some very basic guidelines: + + * Use of whitespace in source files (.java, .c, .h, .cpp, and .hpp files) is + restricted. No TABs, no trailing whitespace on lines, and files should not + terminate in more than one blank line. + * Files with execute permissions should not be added to the source + repositories. + * All generated files need to be kept isolated from the files maintained or + managed by the source control system. The standard area for generated files + is the top level `build/` directory. + * The default build process should be to build the product and nothing else, + in one form, e.g. a product (optimized), debug (non-optimized, -g plus + assert logic), or fastdebug (optimized, -g plus assert logic). + * The `.hgignore` file in each repository must exist and should include + `^build/`, `^dist/` and optionally any `nbproject/private` directories. **It + should NEVER** include anything in the `src/` or `test/` or any managed + directory area of a repository. + * Directory names and file names should never contain blanks or non-printing + characters. + * Generated source or binary files should NEVER be added to the repository + (that includes `javah` output). There are some exceptions to this rule, in + particular with some of the generated configure scripts. + * Files not needed for typical building or testing of the repository should + not be added to the repository. + +***** + + +## Building + +The very first step in building the OpenJDK is making sure the system itself +has everything it needs to do OpenJDK builds. Once a system is setup, it +generally doesn't need to be done again. + +Building the OpenJDK is now done with running a `configure` script which will +try and find and verify you have everything you need, followed by running +`make`, e.g. + +> **`bash ./configure`** +> **`make all`** + +Where possible the `configure` script will attempt to located the various +components in the default locations or via component specific variable +settings. When the normal defaults fail or components cannot be found, +additional `configure` options may be necessary to help `configure` find the +necessary tools for the build, or you may need to re-visit the setup of your +system due to missing software packages. + +**NOTE:** The `configure` script file does not have execute permissions and +will need to be explicitly run with `bash`, see the source guidelines. + +***** + + +### System Setup + +Before even attempting to use a system to build the OpenJDK there are some very +basic system setups needed. For all systems: + + * Be sure the GNU make utility is version 3.81 (4.0 on windows) or newer, e.g. + run "`make -version`" + + + * Install a Bootstrap JDK. All OpenJDK builds require access to a previously + released JDK called the _bootstrap JDK_ or _boot JDK._ The general rule is + that the bootstrap JDK must be an instance of the previous major release of + the JDK. In addition, there may be a requirement to use a release at or + beyond a particular update level. + + **_Building JDK 9 requires JDK 8. JDK 9 developers should not use JDK 9 as + the boot JDK, to ensure that JDK 9 dependencies are not introduced into the + parts of the system that are built with JDK 8._** + + The JDK 8 binaries can be downloaded from Oracle's [JDK 8 download + site](http://www.oracle.com/technetwork/java/javase/downloads/index.html). + For build performance reasons it is very important that this bootstrap JDK + be made available on the local disk of the machine doing the build. You + should add its `bin` directory to the `PATH` environment variable. If + `configure` has any issues finding this JDK, you may need to use the + `configure` option `--with-boot-jdk`. + + * Ensure that GNU make, the Bootstrap JDK, and the compilers are all in your + PATH environment variable. + +And for specific systems: + + * **Linux** + + Install all the software development packages needed including + [alsa](#alsa), [freetype](#freetype), [cups](#cups), and + [xrender](#xrender). See [specific system packages](#SDBE). + + * **Solaris** + + Install all the software development packages needed including [Studio + Compilers](#studio), [freetype](#freetype), [cups](#cups), and + [xrender](#xrender). See [specific system packages](#SDBE). + + * **Windows** + + * Install one of [CYGWIN](#cygwin) or [MinGW/MSYS](#msys) + * Install [Visual Studio 2013](#vs2013) + + * **Mac OS X** + + Install [XCode 4.5.2](https://developer.apple.com/xcode/) and also + install the "Command line tools" found under the preferences pane + "Downloads" + + +#### Linux + +With Linux, try and favor the system packages over building your own or getting +packages from other areas. Most Linux builds should be possible with the +system's available packages. + +Note that some Linux systems have a habit of pre-populating your environment +variables for you, for example `JAVA_HOME` might get pre-defined for you to +refer to the JDK installed on your Linux system. You will need to unset +`JAVA_HOME`. It's a good idea to run `env` and verify the environment variables +you are getting from the default system settings make sense for building the +OpenJDK. + + +#### Solaris + + +##### Studio Compilers + +At a minimum, the [Studio 12 Update 1 Compilers](http://www.oracle.com/ +technetwork/server-storage/solarisstudio/downloads/index.htm) (containing +version 5.10 of the C and C++ compilers) is required, including specific +patches. + +The Solaris SPARC patch list is: + + * 118683-05: SunOS 5.10: Patch for profiling libraries and assembler + * 119963-21: SunOS 5.10: Shared library patch for C++ + * 120753-08: SunOS 5.10: Microtasking libraries (libmtsk) patch + * 128228-09: Sun Studio 12 Update 1: Patch for Sun C++ Compiler + * 141860-03: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C + C++ F77 F95 + * 141861-05: Sun Studio 12 Update 1: Patch for Sun C Compiler + * 142371-01: Sun Studio 12.1 Update 1: Patch for dbx + * 143384-02: Sun Studio 12 Update 1: Patch for debuginfo handling + * 143385-02: Sun Studio 12 Update 1: Patch for Compiler Common patch for Sun C + C++ F77 F95 + * 142369-01: Sun Studio 12.1: Patch for Performance Analyzer Tools + +The Solaris X86 patch list is: + + * 119961-07: SunOS 5.10_x86, x64, Patch for profiling libraries and assembler + * 119964-21: SunOS 5.10_x86: Shared library patch for C++\_x86 + * 120754-08: SunOS 5.10_x86: Microtasking libraries (libmtsk) patch + * 141858-06: Sun Studio 12 Update 1_x86: Sun Compiler Common patch for x86 + backend + * 128229-09: Sun Studio 12 Update 1_x86: Patch for C++ Compiler + * 142363-05: Sun Studio 12 Update 1_x86: Patch for C Compiler + * 142368-01: Sun Studio 12.1_x86: Patch for Performance Analyzer Tools + +Place the `bin` directory in `PATH`. + +The Oracle Solaris Studio Express compilers at: [Oracle Solaris Studio Express +Download site](http://www.oracle.com/technetwork/server-storage/solarisstudio/ +downloads/index-jsp-142582.html) are also an option, although these compilers +have not been extensively used yet. + + +#### Windows + +##### Windows Unix Toolkit + +Building on Windows requires a Unix-like environment, notably a Unix-like +shell. There are several such environments available of which +[Cygwin](http://www.cygwin.com/) and +[MinGW/MSYS](http://www.mingw.org/wiki/MSYS) are currently supported for the +OpenJDK build. One of the differences of these systems from standard Windows +tools is the way they handle Windows path names, particularly path names which +contain spaces, backslashes as path separators and possibly drive letters. +Depending on the use case and the specifics of each environment these path +problems can be solved by a combination of quoting whole paths, translating +backslashes to forward slashes, escaping backslashes with additional +backslashes and translating the path names to their ["8.3" +version](http://en.wikipedia.org/wiki/8.3_filename). + + +###### CYGWIN + +CYGWIN is an open source, Linux-like environment which tries to emulate a +complete POSIX layer on Windows. It tries to be smart about path names and can +usually handle all kinds of paths if they are correctly quoted or escaped +although internally it maps drive letters `| Binary Name | +Category | +Package | +Description | +
| ar.exe | +Devel | +binutils | +The GNU assembler, linker and binary utilities | +
| make.exe | +Devel | +make | +The GNU version of the 'make' utility built for CYGWIN | +
| m4.exe | +Interpreters | +m4 | +GNU implementation of the traditional Unix macro processor | +
| cpio.exe | +Utils | +cpio | +A program to manage archives of files | +
| gawk.exe | +Utils | +awk | +Pattern-directed scanning and processing language | +
| file.exe | +Utils | +file | +Determines file type using 'magic' numbers | +
| zip.exe | +Archive | +zip | +Package and compress (archive) files | +
| unzip.exe | +Archive | +unzip | +Extract compressed files in a ZIP archive | +
| free.exe | +System | +procps | +Display amount of free and used memory in the system | +
| Base OS and Architecture | +OS | +C/C++ Compiler | +Bootstrap JDK | +Processors | +RAM Minimum | +DISK Needs | +
|---|---|---|---|---|---|---|
| Linux X86 (32-bit) and X64 (64-bit) | +Oracle Enterprise Linux 6.4 | +gcc 4.8.2 | +JDK 8 | +2 or more | +1 GB | +6 GB | +
| Solaris SPARCV9 (64-bit) | +Solaris 10 Update 10 | +Studio 12 Update 3 + patches | +JDK 8 | +4 or more | +4 GB | +8 GB | +
| Solaris X64 (64-bit) | +Solaris 10 Update 10 | +Studio 12 Update 3 + patches | +JDK 8 | +4 or more | +4 GB | +8 GB | +
| Windows X86 (32-bit) | +Windows Server 2012 R2 x64 | +Microsoft Visual Studio C++ 2013 Professional Edition | +JDK 8 | +2 or more | +2 GB | +6 GB | +
| Windows X64 (64-bit) | +Windows Server 2012 R2 x64 | +Microsoft Visual Studio C++ 2013 Professional Edition | +JDK 8 | +2 or more | +2 GB | +6 GB | +
| Mac OS X X64 (64-bit) | +Mac OS X 10.9 "Mavericks" | +XCode 5.1.1 or newer | +JDK 8 | +2 or more | +4 GB | +6 GB | +
containsKey
- * method.
- */
- public boolean contains(Object value) {
-
- if (value == null) throw new NullPointerException();
-
- int i;
- HashtableEntry e;
- HashtableEntry tab[] = table;
-
- for (i = tab.length ; i-- > 0 ;) {
- for (e = tab[i] ; e != null ; e = e.next) {
- if (e.value.equals(value)) {
- return true;
- }
- }
- }
- return false;
- }
-
- /**
- * Tests if the specified object is a key in this hashtable.
- */
- public boolean containsKey(Object key) {
- HashtableEntry e;
- HashtableEntry tab[] = table;
- int hash = key.hashCode();
- int index = (hash & 0x7FFFFFFF) % tab.length;
-
- for (e = tab[index] ; e != null ; e = e.next)
- if ((e.hash == hash) && e.key.equals(key))
- return true;
-
- return false;
- }
-
- /**
- * Returns the value to which the specified key is mapped in this hashtable.
- */
- public Object get(Object key) {
- HashtableEntry e;
- HashtableEntry tab[] = table;
- int hash = key.hashCode();
- int index = (hash & 0x7FFFFFFF) % tab.length;
-
- for (e = tab[index] ; e != null ; e = e.next)
- if ((e.hash == hash) && e.key.equals(key))
- return e.value;
-
- return null;
- }
-
- /**
- * Rehashes the contents of the hashtable into a hashtable with a
- * larger capacity. This method is called automatically when the
- * number of keys in the hashtable exceeds this hashtable's capacity
- * and load factor.
- */
- protected void rehash() {
- HashtableEntry e, old;
- int i, index;
- int oldCapacity = table.length;
- HashtableEntry oldTable[] = table;
-
- int newCapacity = oldCapacity * 2 + 1;
- HashtableEntry newTable[] = new HashtableEntry[newCapacity];
-
- threshold = (int)(newCapacity * loadFactor);
- table = newTable;
-
- for (i = oldCapacity ; i-- > 0 ;) {
- for (old = oldTable[i] ; old != null ; ) {
- e = old;
- old = old.next;
- index = (e.hash & 0x7FFFFFFF) % newCapacity;
- e.next = newTable[index];
- newTable[index] = e;
- }
- }
- }
-
- /**
- * Maps the specified key to the specified
- * value in this hashtable. Neither the key nor the
- * value can be null.
- *
- * The value can be retrieved by calling the
* Creates an element of the given qualified name and namespace URI.
@@ -2056,7 +2078,7 @@ extends ParentNode implements Document {
* @since WD-DOM-Level-2-19990923
*/
public Element createElementNS(String namespaceURI, String qualifiedName)
- throws DOMException {
+ throws DOMException {
return new ElementNSImpl(this, namespaceURI, qualifiedName);
}
@@ -2075,8 +2097,8 @@ extends ParentNode implements Document {
* name contains an invalid character.
*/
public Element createElementNS(String namespaceURI, String qualifiedName,
- String localpart)
- throws DOMException {
+ String localpart)
+ throws DOMException {
return new ElementNSImpl(this, namespaceURI, qualifiedName, localpart);
}
@@ -2099,7 +2121,7 @@ extends ParentNode implements Document {
* @since WD-DOM-Level-2-19990923
*/
public Attr createAttributeNS(String namespaceURI, String qualifiedName)
- throws DOMException {
+ throws DOMException {
return new AttrNSImpl(this, namespaceURI, qualifiedName);
}
@@ -2119,8 +2141,8 @@ extends ParentNode implements Document {
* name contains an invalid character.
*/
public Attr createAttributeNS(String namespaceURI, String qualifiedName,
- String localpart)
- throws DOMException {
+ String localpart)
+ throws DOMException {
return new AttrNSImpl(this, namespaceURI, qualifiedName, localpart);
}
@@ -2141,7 +2163,7 @@ extends ParentNode implements Document {
* @since WD-DOM-Level-2-19990923
*/
public NodeList getElementsByTagNameNS(String namespaceURI,
- String localName) {
+ String localName) {
return new DeepNodeListImpl(this, namespaceURI, localName);
}
@@ -2194,11 +2216,11 @@ extends ParentNode implements Document {
if (!xml11Version) {
validNCName = (prefix == null || XMLChar.isValidNCName(prefix))
- && XMLChar.isValidNCName(local);
+ && XMLChar.isValidNCName(local);
}
else {
validNCName = (prefix == null || XML11Char.isXML11ValidNCName(prefix))
- && XML11Char.isXML11ValidNCName(local);
+ && XML11Char.isXML11ValidNCName(local);
}
return validNCName;
@@ -2284,37 +2306,33 @@ extends ParentNode implements Document {
* REVISIT: we could use a free list of UserDataRecord here
*/
public Object setUserData(Node n, String key,
- Object data, UserDataHandler handler) {
+ Object data, UserDataHandler handler) {
if (data == null) {
- if (userData != null) {
- Hashtable t = (Hashtable) userData.get(n);
+ if (nodeUserData != null) {
+ Map Important Note: You are responsible for removing references
* to your data on nodes that are no longer used. Failure to do so will
* prevent the nodes, your data is attached to, to be garbage collected
diff --git a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java
index 3481afe1f6a..3949063a5ab 100644
--- a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java
+++ b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java
@@ -1,13 +1,13 @@
/*
- * reserved comment block
- * DO NOT REMOVE OR ALTER!
+ * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
*/
/*
- * Copyright 1999-2002,2004,2005 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
@@ -1022,7 +1022,7 @@ public abstract class ParentNode
/*
* a class to store some user data along with its handler
*/
- class UserDataRecord implements Serializable {
+ protected class UserDataRecord implements Serializable {
/** Serialization version. */
private static final long serialVersionUID = 3258126977134310455L;
diff --git a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java
index cf5f3b9059b..fdbd960bfb3 100644
--- a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java
+++ b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java
@@ -331,7 +331,7 @@ public class XML11DocumentScannerImpl
new Object[]{entityName});
}
}
- fEntityManager.startEntity(entityName, true);
+ fEntityManager.startEntity(false, entityName, true);
}
}
}
diff --git a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
index 269c9105bb6..ca6af1ccd9d 100644
--- a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
+++ b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
@@ -1,62 +1,21 @@
/*
- * reserved comment block
- * DO NOT REMOVE OR ALTER!
+ * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
*/
+
/*
- * The Apache Software License, Version 1.1
+ * Copyright 2005 The Apache Software Foundation.
*
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
*
- * Copyright (c) 1999-2002 The Apache Software Foundation.
- * All rights reserved.
+ * http://www.apache.org/licenses/LICENSE-2.0
*
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in
- * the documentation and/or other materials provided with the
- * distribution.
- *
- * 3. The end-user documentation included with the redistribution,
- * if any, must include the following acknowledgment:
- * "This product includes software developed by the
- * Apache Software Foundation (http://www.apache.org/)."
- * Alternately, this acknowledgment may appear in the software itself,
- * if and wherever such third-party acknowledgments normally appear.
- *
- * 4. The names "Xerces" and "Apache Software Foundation" must
- * not be used to endorse or promote products derived from this
- * software without prior written permission. For written
- * permission, please contact apache@apache.org.
- *
- * 5. Products derived from this software may not be called "Apache",
- * nor may "Apache" appear in their name, without prior written
- * permission of the Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * ====================================================================
- *
- * This software consists of voluntary contributions made by many
- * individuals on behalf of the Apache Software Foundation and was
- * originally based on software copyright (c) 1999, International
- * Business Machines, Inc., http://www.apache.org. For more
- * information on the Apache Software Foundation, please see
- * get method
- * with a key that is equal to the original key.
- */
- public Object put(Object key, Object value) {
- // Make sure the value is not null
- if (value == null) throw new NullPointerException();
-
- // Makes sure the key is not already in the hashtable.
- HashtableEntry e;
- HashtableEntry tab[] = table;
- int hash = key.hashCode();
- int index = (hash & 0x7FFFFFFF) % tab.length;
-
- for (e = tab[index] ; e != null ; e = e.next) {
- if ((e.hash == hash) && e.key.equals(key)) {
- Object old = e.value;
- e.value = value;
- return old;
- }
- }
-
- // Rehash the table if the threshold is exceeded
- if (count >= threshold) {
- rehash();
- return put(key, value);
- }
-
- // Creates the new entry.
- e = new HashtableEntry();
- e.hash = hash;
- e.key = key;
- e.value = value;
- e.next = tab[index];
- tab[index] = e;
- count++;
- return null;
- }
-
- /**
- * Removes the key (and its corresponding value) from this
- * hashtable. This method does nothing if the key is not in the hashtable.
- */
- public Object remove(Object key) {
- HashtableEntry e, prev;
- HashtableEntry tab[] = table;
- int hash = key.hashCode();
- int index = (hash & 0x7FFFFFFF) % tab.length;
- for (e = tab[index], prev = null ; e != null ; prev = e, e = e.next) {
- if ((e.hash == hash) && e.key.equals(key)) {
- if (prev != null)
- prev.next = e.next;
- else
- tab[index] = e.next;
- count--;
- return e.value;
- }
- }
- return null;
- }
-
- /**
- * Clears this hashtable so that it contains no keys.
- */
- public void clear() {
- HashtableEntry tab[] = table;
- for (int index = tab.length; --index >= 0; )
- tab[index] = null;
- count = 0;
- }
-
- /**
- * Returns a rather long string representation of this hashtable.
- * Handy for debugging - leave it here!!!
- */
- public String toString() {
- int i;
- int max = size() - 1;
- StringBuffer buf = new StringBuffer();
- Enumeration k = keys();
- Enumeration e = elements();
- buf.append("{");
-
- for (i = 0; i <= max; i++) {
- String s1 = k.nextElement().toString();
- String s2 = e.nextElement().toString();
- buf.append(s1).append('=').append(s2);
- if (i < max) buf.append(", ");
- }
- buf.append("}");
- return buf.toString();
- }
-
- /**
- * A hashtable enumerator class. This class should remain opaque
- * to the client. It will use the Enumeration interface.
- */
- class HashtableEnumerator implements Enumeration {
- boolean keys;
- int index;
- HashtableEntry table[];
- HashtableEntry entry;
-
- HashtableEnumerator(HashtableEntry table[], boolean keys) {
- this.table = table;
- this.keys = keys;
- this.index = table.length;
- }
-
- public boolean hasMoreElements() {
- if (entry != null) {
- return true;
- }
- while (index-- > 0) {
- if ((entry = table[index]) != null) {
- return true;
- }
- }
- return false;
- }
-
- public Object nextElement() {
- if (entry == null) {
- while ((index-- > 0) && ((entry = table[index]) == null));
- }
- if (entry != null) {
- HashtableEntry e = entry;
- entry = e.next;
- return keys ? e.key : e.value;
- }
- return null;
- }
- }
-
-}
diff --git a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java
index be2925824ff..0ed98009a06 100644
--- a/jaxp/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java
+++ b/jaxp/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java
@@ -1,13 +1,13 @@
/*
- * reserved comment block
- * DO NOT REMOVE OR ALTER!
+ * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved.
*/
/*
- * Copyright 2001-2004 The Apache Software Foundation.
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
@@ -24,14 +24,15 @@
package com.sun.org.apache.xalan.internal.xsltc.trax;
+import com.sun.org.apache.xalan.internal.xsltc.dom.SAXImpl;
+import com.sun.org.apache.xalan.internal.xsltc.runtime.BasisLibrary;
import java.io.IOException;
-import java.util.Hashtable;
+import java.util.HashMap;
+import java.util.Map;
import java.util.Stack;
import java.util.Vector;
-
import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
-
import org.xml.sax.ContentHandler;
import org.xml.sax.DTDHandler;
import org.xml.sax.EntityResolver;
@@ -44,8 +45,6 @@ import org.xml.sax.SAXNotSupportedException;
import org.xml.sax.XMLReader;
import org.xml.sax.ext.LexicalHandler;
import org.xml.sax.helpers.AttributesImpl;
-import com.sun.org.apache.xalan.internal.xsltc.dom.SAXImpl;
-import com.sun.org.apache.xalan.internal.xsltc.runtime.BasisLibrary;
/**
* @author G. Todd Miller
@@ -59,7 +58,7 @@ public class DOM2SAX implements XMLReader, Locator {
private ContentHandler _sax = null;
private LexicalHandler _lex = null;
private SAXImpl _saxImpl = null;
- private Hashtable _nsPrefixes = new Hashtable();
+ private MappreventDefault()
* method was invoked by an EventListener; otherwise false.
*/
+ @Override
protected boolean dispatchEvent(NodeImpl node, Event event) {
if (event == null) return false;
@@ -690,11 +715,11 @@ public class DocumentImpl
// is issued to the Element rather than the Attr
// and causes a _second_ DOMSubtreeModified in the Element's
// tree.
- Vector pv = new Vector(10,10);
+ List